ETSI TS 100 939 vs.s.i (1999-11) 

Technical Specification 



Digital cellular telecommunications system (Phase 2+); 

Mobile radio interface signalling layer 3; 

General aspects 
(GSM 04.07 version 6.5.1 Release 1997) 



G5 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 




(GSM 04.07 version 6.5.1 Release 1 997) 2 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 



Reference 



RTS/SMG-030407Q6R3 (8p0031or.PDF) 

Keywords 

Digital cellular telecommunications system, 

Global System for Mobile communications (GSM) 



ETSI 

Postal address 



F-06921 Sophia Antipolis Cedex - FRANCE 

Office address 

650 Route des Lucioles - Sophia Antipolis 

Valbonne - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N " 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Internet 



secretariat@etsi.fr 

Individual copies of this ETSI deliverable 

can be downloaded from 

http://www.etsi.org 

If you find errors in the present document, send your 

comment to: editor@etsi.fr 



Important notice 



This ETSI deliverable may be made available in more than one electronic version or in print. In any case of existing or 
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 
In case of dispute, the reference should be the printing on ETSI printers of the PDF version kept on a specific network 

drive within ETSI Secretariat. 



Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 



I European Telecommunications Standards Institute 1999. 
All rights reserved. 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 3 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 



Contents 



Intellectual Property Rights 11 

Foreword 11 

1 Scope 12 

2 References 12 

3 Abbreviations 13 

4 Introduction 13 

4.1 General 13 

4.2 Applicability of functional blocks 15 

4.3 Technique of description 15 

4.3.1 Service description 15 

4.3.2 Abstract service primitives 15 

4.3.3 Protocols and peer-to-peer communication 15 

4.3.4 Contents of layer 3 related Technical Specifications 16 

5 Structure of layer 3 functions 17 

5.1 Basic groups of functions 17 

5.2 Protocol architecture 18 

6 Services provided by signalling layer 3 at the MS side 22 

6.1 Registration services 23 

6.1.1 Service state diagram for MS not supporting GPRS service 23 

6.1.2 Service primitives 23 

6.1.2.1 MMR_REG_REQ 23 

6.1.2.2 MMR_REG_CNF 23 

6.1.2.3 [reserved] 24 

6.1.2.4 MMR_NREG_REQ 24 

6.1.2.5 MMR_NREG_1ND 24 

6.2 Call Control services 24 

6.2.1 Service state diagram 24 

6.2.2 Service primitives 27 

6.2.2.1 MNCC_SETUP_REQ 27 

6.2.2.2 MNCC_SETUP_1ND 27 

6.2.2.3 MNCC_SETUP_RES 28 

6.2.2.4 MNCC_SETUP_CNF 28 

6.2.2.5 MNCC_SETUP_COMPL_REQ 28 

6.2.2.6 MNCC_SETUP_C0MPL_1ND 28 

6.2.2.7 MNCC_REJ_REQ 28 

6.2.2.8 MNCC_REJ_1ND 28 

6.2.2.9 MNCC_CALL_CONF_REQ 28 

6.2.2.10 MNCC_CALL_PROC_IND 28 

6.2.2.11 MNCC_PR0GRESS_1ND 28 

6.2.2.12 MNCC_ALERT_REQ 28 

6.2.2.13 MNCC_ALERT_1ND 28 

6.2.2.14 MNCC_N0T1FY_REQ 28 

6.2.2.15 MNCC_N0T1FY_1ND 29 

6.2.2.16 MNCC_D1SC_REQ 29 

6.2.2.17 MNCC_D1SC_1ND 29 

6.2.2.18 MNCC_REL_REQ 29 

6.2.2.19 MNCC_REL_IND 29 

6.2.2.20 MNCC_REL_CNF 29 

6.2.2.21 MNCC_FAC1L1TY_REQ 29 

6.2.2.22 MNCC_FAC1L1TY_1ND 29 

6.2.2.23 MNCC_START_DTMF_REQ 29 

6.2.2.24 MNCC_START_DTMF_CNF 29 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 4 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

6.2.2.25 MNCC_STOP_DTMF_REQ 29 

6.2.2.26 MNCC_STOP_DTMF_CNF 29 

6.2.2.27 MNCC_MODIFY_REQ 30 

6.2.2.28 MNCC_MODIFY_IND 30 

6.2.2.29 MNCC_MODIFY_RES 30 

6.2.2.30 MNCC_MODIFY_CNF 30 

6.2.2.31 MNCC_SYNC_IND 30 

6.3 Call independent Supplementary Services Support 30 

6.3.1 Service state diagram 30 

6.3.2 Service primitives 31 

6.3.2.1 MNSS_BEG1N_REQ 31 

6.3.2.2 MNSS_BEGIN_1ND 31 

6.3.2.3 MNSS_FACIL1TY_REQ 31 

6.3.2.4 MNSS_FAC1L1TY_1ND 31 

6.3.2.5 MNSS_END_REQ 31 

6.3.2.6 MNSS_END_1ND 31 

6.4 Short Message Services Support 31 

6.5 Session Management Services for GPRS-Services 31 

6.5.1 Session Management Services for SMREG-SAP 32 

6.5.1.1 SMREG-PDP-ACTIVATE-REQ 32 

6.5.1.2 SMREG-PDP-ACTIVATE-CNF 32 

6.5.1.3 SMREG-PDP-ACTIVATE-REJ 32 

6.5.1.4 SMREG-PDP-ACTIVATE-IND 32 

6.5.1.5 SMREG-PDP-DEACTIVATE-REQ 33 

6.5.1.6 SMREG-PDP-DEACTIVATE-CNF 33 

6.5.1.7 SMREG-PDP-DEACTIVATE-IND 33 

6.5.1.8 SMREG-PDP-MODIFY-IND 33 

6.5.1.9 SMREG-AA-PDP-ACTIVATE-REQ 33 

6.5.1.10 SMREG-AA-PDP-ACTIVATE-CNF 33 

6.5.1.11 SMREG-AA-PDP-ACTIVATE-REJ 33 

6.5.1.12 SMREG-AA-PDP-DEACTIVATE-REQ 33 

6.5.1.13 SMREG-AA-PDP-DEACTIVATE-IND 33 

6.5.2 Session Management Services for SNSM-SAP 35 

6.5.2.1 Service primitives 35 

6.5.2.1.1 SNSM-ACTIVATE-IND 35 

6.5.2.1.2 SNSM-ACTIVATE-RSP 35 

6.5.2.1.3 SNSM-DEACTIVATE-IND 35 

6.5.2.1.4 SNSM-DEACTIVATE-RSP 35 

6.5.2.1.5 SNSM-MODIFY-IND 35 

6.5.2.1.6 SNSM-MODIFY-RSP 35 

6.5.2.1.7 SNSM-STATUS-REQ 36 

6.6 Registration Services for GPRS-Services 36 

6.6.1 Registration Services for GMMREG-SAP 36 

6.6.1.1 GMMREG-ATTACH-REQ 36 

6.6.1.2 GMMREG-ATTACH-CNF 36 

6.6.1.3 GMMREG-ATTACH-REJ 36 

6.6.1.4 GMMREG-DETACH-REQ 36 

6.6.1.5 GMMREG-DETACH-CNF 37 

6.6.1.6 GMMREG-DETACH-IND 37 

6.7 Services provided to SNDCP entities by GPRS Logical Link Control services 37 

6.7.1 Service state diagram for QoSl-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP 38 

6.7.2 Service primitives for QoSl-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP 39 

6.7.2.1 LL-ESTABLISH-REQ 39 

6.7.2.2 LL-ESTABLISH-CNF 39 

6.7.2.3 LL-ESTABLISH-IND 39 

6.7.2.4 LL-ESTABLISH-RSP 39 

6.7.2.5 LL-RELEASE-REQ 40 

6.7.2.6 LL-RELEASE-CNF 40 

6.7.2.7 LL-RELEASE-IND 40 

6.7.2.8 LL-XID-REQ 40 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 5 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

6.7.2.9 LL-XID-IND 40 

6.7.2.10 LL-XID-RSP 40 

6.7.2.11 LL-XID-CNF 40 

6.7.2.12 LL-DATA-REQ 40 

6.7.2.13 LL-DATA-CNF 40 

6.7.2.14 LL-DATA-IND 40 

6.7.2.15 LL-UNITDATA-REQ 40 

6.7.2.16 LL-UNITDATA-IND 40 

6.7.2.17 LL-STATUS-IND 40 

7 Services provided by signalling layer 3 on the Network side 41 

7.1 Call control services 41 

7.1.1 Service state diagram 41 

7.1.2 Service primitives 44 

7.1.2.1 MNCC_SETUP_REQ 44 

7.1.2.2 MNCC_SETUP_1ND 44 

7.1.2.3 MNCC_SETUP_RSP 44 

7.1.2.4 MNCC_SETUP_CNF 45 

7.1.2.5 MNCC_SETUP_COMPL_REQ 45 

7.1.2.6 MNCC_SETUP_COMPL_lND 45 

7.1.2.7 MNCC_REJ_REQ 45 

7.1.2.8 MNCC_REJ_1ND 45 

7.1.2.9 MNCC_CALL_C0NF_1ND 45 

7.1.2.10 MNCC_CALL_PROC_REQ 45 

7.1.2.11 MNCC_PROGRESS_REQ 45 

7.1.2.12 MNCC_ALERT_REQ 45 

7.1.2.13 MNCC_ALERT_1ND 45 

7.1.2.14 MNCC_N0T1FY_REQ 45 

7.1.2.15 MNCC_N0T1FY_1ND 45 

7.1.2.16 MNCC_D1SC_REQ 46 

7.1.2.17 MNCC_D1SC_1ND 46 

7.1.2.18 MNCC_REL_REQ 46 

7.1.2.19 MNCC_REL_1ND 46 

7.1.2.20 MNCC_REL_CNF 46 

7.1.2.21 MNCC_FAC1L1TY_REQ 46 

7.1.2.22 MNCC_FAC1L1TY_1ND 46 

7.1.2.23 MNCC_START_DTMF_1ND 46 

7.1.2.24 MNCC_START_DTMF_RSP 46 

7.1.2.25 MNCC_STOP_DTMF_lND 46 

7.1.2.26 MNCC_STOP_DTMF_RSP 46 

7.1.2.27 MNCC_M0D1FY_REQ 46 

7.1.2.28 MNCC_M0D1FY_1ND 46 

7.1.2.29 MNCC_MODlFY_RES 47 

7.1.2.30 MNCC_MODlFY_CNF 47 

7.2 Call independent Supplementary Services Support 47 

7.2.1 Service state diagram 47 

7.2.2 Service primitives 48 

7.2.2.1 MNSS_BEG1N_REQ 48 

7.2.2.2 MNSS_BEG1N_1ND 48 

7.2.2.3 MNSS_FAC1L1TY_REQ 48 

7.2.2.4 MNSS_FAC1L1TY_1ND 48 

7.2.2.5 MNSS_END_REQ 48 

7.2.2.6 MNSS_END_1ND 48 

7.3 Short Message Services Support 48 

7.4 Services provided to SNDCP and SMS entities by GPRS Logical Link Control services 48 

7.4.1 Service state diagram for QoSl-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP 49 

7.4.2 Service primitives for QoSl-SAP,QoS2-SAP,QoS3-SAP and QoS4-SAP 49 

7.4.2.1 LL-ESTABLISH-REQ 49 

7.4.2.2 LL-ESTABLISH-CNF 49 

7.4.2.3 LL-ESTABLISH-IND 49 

7.4.2.4 LL-ESTABLISH-RSP 50 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 6 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

7.4.2.5 LL-RELEASE-REQ 50 

7.4.2.6 LL-RELEASE-CNF 50 

7.4.2.7 LL-RELEASE-IND 50 

7.4.2.8 LL-XID-REQ 50 

7.4.2.9 LL-XID-IND 50 

7.4.2.10 LL-XID-RSP 50 

7.4.2.11 LL-XID-CNF 50 

7.4.2.12 LL-DATA-REQ 50 

7.4.2.13 LL-DATASENT-IND 50 

7.4.2.14 LL-DATA-CNF 50 

7.4.2.15 LL-DATA-IND 50 

7.4.2.16 LL-UNITDATA-REQ 50 

7.4.2.17 LL-UNITDATA-IND 50 

7.4.2.18 LL-STATUS-IND 51 

7.5 Session Management Services for GPRS 51 

7.5.1 Session Management Services for SMREG-SAP 51 

7.5.1.1 SMREG-PDP-ACTIVATE-REQ 51 

7.5.1.2 SMREG-PDP-ACTIVATE-REJ 51 

7.5.1.3 SMREG-PDP-DEACTIVATE-REQ 51 

7.5.1.4 SMREG-PDP-DEACTIVATE-CNF 51 

7.5.1.5 SMREG-PDP-MODIFY-REQ 51 

7.5.1.6 SMREG-PDP-MODIFY-CNF 52 

7.5.1.7 SMREG-PDP-MODIFY-REJ 52 

7.5.2 Session Management Services for SNSM-SAP 52 

7.5.2.1 SNSM-ACTIVATE-IND 52 

7.5.2.2 SNSM-ACTIVATE-RSP 52 

7.5.2.3 SNSM-DEACTIVATE-IND 52 

7.5.2.4 SNSM-DEACTIVATE-RSP 52 

7.5.2.5 SNSM-MODIFY-IND 53 

7.5.2.6 SNSM-MODIFY-RSP 53 

7.5.2.7 SNSM-STATUS-REQ 53 

7.5.2.8 SNSM-WINDOW-IND 53 

8 Services assumed from signalling layers 1 and 2 53 

8.1 Priority 53 

8.2 Unacknowledged information transfer 53 

8.3 Acknowledged information transfer 54 

8.4 Random access 54 

8.5 Channel management and measurements 54 

9 Interlayer service interfaces on the MS side 54 

9.1 Services provided by the Radio Resource Management entity 54 

9.1.1 Service state diagram 55 

9.1.2 Service primitives 56 

9.1.2.1 RR_EST_REQ 56 

9.1.2.2 RR_EST_1ND 56 

9.1.2.3 RR_EST_CNF 56 

9.1.2.4 RR_REL_IND 56 

9.1.2.5 RR_SYNC_IND 56 

9.1.2.6 RR_DATA_REQ 56 

9.1.2.7 RR_DATA_IND 57 

9.1.2.8 RR_UN1T_DATA_1ND 57 

9.1.2.9 RR_ABORT_REQ 57 

9.1.2.10 RR_ABORT_IND 57 

9.2 Services provided by the Mobility Management entity 57 

9.2.1 Service state diagram 58 

9.2.2 Service primitives 59 

9.2.2.1 MMXX_EST_REQ 59 

9.2.2.2 MMXX_EST_1ND 59 

9.2.2.3 MMXX_EST_CNF 59 

9.2.2.4 MMXX_REL_REQ 59 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 7 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

9.2.2.5 MMXX_REL_IND 59 

9.2.2.6 MMXX_DATA_REQ 60 

9.2.2.7 MMXX_DATA_IND 60 

9.2.2.8 MMXX_UNIT_DATA_REQ 60 

9.2.2.9 MMXX_UNIT_DATA_IND 60 

9.2.2.10 MMCC_SYNC_IND 60 

9.2.2.11 MMXX_REEST_REQ 60 

9.2.2.12 MMXX_REEST_CNF 60 

9.2.2.13 MMXX_ERR_IND 60 

9.2.2.14 MMXX_PROMPT_IND 60 

9.2.2.15 MMXX_PROMPT_REJ 60 

9.3 Services provided by radio resource management entity for GPRS services 60 

9.3.1 Service primitives for GRR-SAP 61 

9.3.1.1 GRR-DATA-REQ 61 

9.3.1.2 GRR-DATA-IND 61 

9.3.1.3 GRR-UNITDATA-REQ 61 

9.3.1.4 GRR-UNITDATA-IND 61 

9.3.1.5 GRR-STATUS-IND 61 

9.3.2 Service primitives for GMMRR-SAP 61 

9.3.2.1 GMMRR-ASSIGN-REQ 61 

9.3.2.2 GMMRR-PAGE-IND 61 

9.4 Services provided by the LLC entity for GPRS services 62 

9.4.1 Service primitives for LLGMM-SAP 62 

9.4.1.1 LLGMM-ASSIGN-REQ 62 

9.4.1.2 LLGMM-TRIGGER-REQ 62 

9.4.1.3 LLGMM-TRIGGER-IND 62 

9.4.1.4 LLGMM-SUSPEND-REQ 62 

9.4.1.5 LLGMM-RESUME-REQ 62 

9.4.1.6 LLGMM-WINDOW-REQ 62 

9.4.1.7 LLGMM-WINDOW-CNF 63 

9.4.1.8 LL-UNITDATA-REQ 63 

9.4.1.9 LL-UNITDATA-IND 63 

9.4.1.10 LLGMM-STATUS-IND 63 

9.4.2 Service primitives for LLSMS-SAP 63 

9.4.2.1 LL-UNITDATA-REQ 63 

9.4.2.2 LL-UNITDATA-IND 63 

9.5 Registration Services provided for GPRS Services 63 

9.5.1 Service primitives for GMMSM-SAP 63 

9.5.1.1 GMMSM-ESTABLISH-REQ 64 

9.5.1.2 GMMSM-ESTABLISH-CNF 64 

9.5.1.3 GMMSM-ESTABLISH-REJ 64 

9.5.1.4 GMMSM-RELEASE-IND 64 

9.5.1.5 GMMSM-UNITDATA-REQ 64 

9.5.1.6 GMMSM-UNITDATA-IND 64 

9.5.2 Service primitives for GMMAA-SAP 64 

9.5.2.1 GMMAA-ESTABLISH-REQ 65 

9.5.2.2 GMMAA-RELEASE-IND 65 

9.5.2.3 GMMAA-ESTABLISH-REJ 65 

9.5.3 Service primitives for GMMSMS-SAP 65 

9.5.3.1 GMMSMS-REG-STATE-REQ 65 

9.5.3.2 GMMSM- REG-STATE -RSP 65 

10 Interlayer service interfaces on the Network side 65 

10.1 Services provided by the Radio Resource Management entity 66 

10.1.1 Service state diagram 66 

10.1.2 Service primitives 67 

10.1.2.1 RR_EST_REQ 67 

10.1.2.2 RR_EST_IND 68 

10.1.2.3 RR_EST_CNF 68 

10.1.2.4 RR_REL_REQ 68 

10.1.2.5 RR REL IND 68 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 8 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

RR_SYNC_REQ 68 

RR_SYNC_CNF 68 

RR_DATA_REQ 68 

RR_DATA_IND 68 

RR_UNIT_DATA_REQ 68 

RR_UNIT_DATA_IND 68 

RR_ABORT_REQ 68 

RR_ABORT_IND 68 

Services provided by the Mobility Management entity 68 

Service state diagram 69 

Service primitives 70 

MMXXj;ST_REQ 70 

MMXX_EST_IND 70 

MMXX_EST_CNF 70 

MMXX_REL_REQ 70 

MMXX_REL_IND 70 

MMXX_DATA_REQ 70 

MMXX_DATA_IND 70 

MMXX_UNIT_DATA_REQ 70 

MMXX_UNIT_DATA_IND 70 

MMCC_SYNC_REQ 71 

MMCC_SYNC_CNF 71 

Services provided by radio resource management entity for GPRS services 71 

Service primitives for GRR-SAP 72 

GRR-DATA-REQ 72 

GRR-DATA-IND 72 

GRR-UNITDATA-REQ 72 

GRR-UNITDATA-IND 72 

GRR-STATUS-IND 72 

Service primitives for GMMRR-SAP 72 

GMMRR-PAGE-REQ 72 

Services provided by the LLC entity for GPRS services 73 

Service primitives for LLGMM-SAP 73 

LLGMM-ASSIGN-REQ 73 

LLGMM-TRIGGER-IND 73 

LLGMM-SUSPEND-REQ 73 

LLGMM-RESUME-REQ 73 

LLGMM-WINDOW-REQ 73 

LLGMM-WINDOW-CNF 73 

LLGMM-PAGE-IND 74 

LLGMM-PAGE-RESP-IND 74 

LL-UNITDATA-REQ 74 

LL-UNITDATA-IND 74 

LLGMM-STATUS-IND 74 

Service primitives for LLSMS-SAP 74 

LL-UNITDATA-REQ 74 

LL-UNITDATA-IND 74 

Services provided by the GMM for GPRS services 74 

10.5.1 Service primitives for GMMSM-SAP 74 

10.5.1.1 GMMSM-RELEASE-IND 75 

10.5.1.2 GMMSM-UNITDATA-REQ 75 

10.5.1.3 GMMSM-UNITDATA-IND 75 

11 L3 Messages 75 

11.1 General 75 

11.1.1 Messages 75 

11.1.2 Octets 76 

11.1.3 Integer 76 

11.1.3.1 Binary 76 

11.1.3.2 2-complement binary 76 

11.1.4 Spare parts 77 



£75/ 



.1.2.6 


.1.2.7 


.1.2.8 


.1.2.9 


.1.2.10 


.1.2.11 


.1.2.12 


.1.2.13 


.2 


.2.1 


.2.2 


.2.2.1 


.2.2.2 


.2.2.3 


.2.2.4 


.2.2.5 


.2.2.6 


.2.2.7 


.2.2.8 


.2.2.9 


.2.2.10 


.2.2.11 


.3 


.3.1 


.3.1.1 


.3.1.2 


.3.1.3 


.3.1.4 


.3.1.5 


.3.2 


.3.2.1 


.4 


.4.1 


.4.1.1 


.4.1.2 


.4.1.3 


.4.1.4 


.4.1.5 


.4.1.6 


.4.1.7 


.4.1.8 


.4.1.9 


.4.1.10 


.4.1.11 


.4.2 


.4.2.1 


.4.2.2 


.5 



(GSM 04.07 version 6.5.1 Release 1 997) 9 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

11.2 Standard L3 messages 77 

11.2.1 Components of a standard L3 message 77 

11.2.1.1 Format of standard information elements 77 

11.2.1.1.1 Information element type and value part 77 

11.2.1.1.2 Length indicator 78 

11.2.1.1.3 Information element identifier 78 

11.2.1.1.4 Categories of IBs; order of occurrence of lEI, LI, and value part 78 

11.2.2 Description methods for IE structure 80 

11.2.2.1 Tables 80 

11.2.2.1.1 Compact notation 80 

11.2.3 Imperative part of a standard L3 message 80 

11.2.3.1 Header 81 

11.2.3.1.1 Protocol discriminator 81 

11.2.3.1.2 Skip indicator 81 

11.2.3.1.3 Transaction identifier 81 

11.2.3.2 Message type octet 82 

11.2.3.3 Standard information elements of the imperative part 83 

11.2.4 Non-imperative part of a standard L3 message 83 

11.2.5 Presence requirements of information elements 84 

11.2.6 Description of standard L3 messages 85 

11.3 Non standard L3 messages 85 

11.3.1 Case A : BCCH and AGCH/PCH messages 85 

11.3.1.1 L2 Pseudo Length octet 85 

11.3.1.2 Rest Octets 86 

11.3.1.3 Description of a modified standard L3 message 86 

11.3.2 Case B : SACCH messages sent in unacknowledged mode 86 

11.3.2.1 The first octet 86 

11.3.2.2 The rest of the message 86 

11.3.3 Design guidelines for non standard parts 86 

11.3.3.1 General 86 

11.4 Handling of superfluous information 87 

11.4.1 Information elements that are unnecessary in a message 87 

11.4.2 Other syntactic errors 87 

Annex A (informative): MN-Services arrow diagram 88 

Annex B (informative): Description of CSN.l 95 

B.l The Basic Rules 95 

B.1.1 Core Rules 95 

B.l. 1.1 Rule Bl: Bits 95 

B.l. 1.2 Rule B2 : Null String 95 

B.l. 1.3 RuleB3 : Concatenation 95 

B.l. 1.4 Rule B4 : Choice 96 

B.l. 1.5 Rule B5 : Naming 96 

B.l. 1.6 RuleB6 : Definition 97 

B.l. 2 Spare parts 97 

B. 1.2.1 RuleB7: Spare bits 97 

B. 1.2.2 Rule B8 : Padding bits 97 

B.1.3 Predefined sets 98 

B.1.4 Labelling Parts 98 

B. 1.4.1 RuleAl : Labels 98 

B.1.5 Goodies 99 

B. 1.5.1 RuleGl : Comments 99 

B.2 Advanced rules 99 

B.2.1 Rule A2 : Exponent notation 99 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 1 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

Annex C (informative): GPRS-Services sequence diagram 101 

Annex D (informative): Change Request History 119 

History 120 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 1 1 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314; "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server 
(http ://www. etsi.org/ipr) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document defines the architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the interface 
between Mobile Station and network within the digital cellular telecommunications system (Phase 2+). 

The contents of the present document may be subject to continuing work within SMG and may change following formal 
SMG approval. Should SMG modify the contents of the present document it will then be re-submitted for formal 
approval procedures by ETSI with an identifying change of release date and an increase in version number as follows: 

Version 6.x.y 

where: 

6 GSM Phase 2+ Release 1997 

X the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, 
etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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Scope 



The present document defines the principal architecture of layer 3 and its sublayers on the GSM Um interface, i.e. the 
interface between Mobile Station (MS) and network; for the CM sublayer, the description is restricted to paradigmatic 
examples, call control, supplementary services, and short message services for non-GPRS services. It also defines the 
basic message format and error handling applied by the layer 3 protocols. 

The corresponding protocols are defined in other Technical Specifications, see subclause 4.3.4. 

For non-GPRS services the communication between sublayers and adjacent layers and the services provided by the 
sublayers are distributed by use of abstract service primitives. But only externally observable behaviour resulting from 
the description is normatively prescribed by this Technical Specification. 

For GPRS services in addition the local information transfer and stimuli sent between sublayers is informatively 
included within Annex C of in this Technical Specification. 
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Abbreviations 



Abbreviations used in the present document, are listed in GSM 01.04. 

For the purposes of the present document, the following abbreviations applies: 

GMM GPRS Mobility Management 

MNS Mobile Network Signalling 

N-PDU Network Protocol Data Unit 

SM Session Management 

UDT User Data Transfer 



4 Introduction 

4.1 General 

Three models are defined for Layer 3, one model for non-GPRS services, one for GPRS services supporting Class C 
MSs only and one model for GPRS-services supporting Class A and Class B MSs. (The third model is a combination of 
the first two models listed). 
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The layer 3 for non-GPRS services provides the functions necessary: 
for Radio Resource (RR) management; 

- for Mobility Management (MM); and 

for the Connection Management (CM) functions, i.e. functions for the control, provision, and support of services 
offered by the network; among which there are, e.g.: 

the functions to establish, maintain and terminate circuit-switched connections across a GSM PLMN and- 
other networks to which the GSM PLMN is connected; 

supporting functions for supplementary services control; 

supporting functions for short messages service control. 

The layer 3 for non-GPRS services is composed of three sublayers comprising: 

the Radio Resource Management (RR) functions; 

the Mobility Management (MM) functions; and 

the Connection Management (CM) functions. 

The layer 3 for GPRS services is composed of four sublayers comprising : 

the Radio Resource Management (RR) functions; 

- the Mobility Management (GMM and GMM-AA); 
for the Logical Link Control (LLC); 

the Connection Management (CM) functions. 

Session Management (SM) functions to activate, modify and delete the contexts for packet data protocols (PDP) 
supporting functions for short messages service control. 
The Connection Management (CM) sublayer is composed of functional blocks for: 

- Call Control (CC) for non-GPRS services; 

- Short Message Service Support (SMS) for non-GPRS services; 

- GPRS Short Message Service Support (GSMS) (for GPRS services supporting Class A, B and C MSs); 
Session Management (SM) (for GPRS services supporting Class A, B and C MSs); 
Supplementary Services Support (SS) for non-GPRS services; 

Group Call Control for non-GPRS services; 

- Broadcast Call Control (BCC) for non-GPRS services; 

Connection Management of Packet Data on Signalling channels for non-GPRS services. 

The present document does not consider the distribution of signalling functions among the different network 
equipments. The signalling functions are described between two systems which represent the MS side and the network 
side of the radio interface of layer 3. Only the functions in the network for signalling communication with one MS is 
considered. 

For GPRS services, in addition to the signalling functions also the user data transfer is included in this Technical 
Specification. 
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4.2 Applicability of functional blocks 

Not for all functional blocks listed in subclause 4. 1, support in the MS or in the network is mandatory: 

Support of Group Call Control is optional in the MS and in the network. 

Support of Broadcast Call Control is optional in the MS and in the network. 

Connection Management of Packet Data on Signalling channels, is optional in the MS and in the network. 

Support of GPRS services is optional in the MS and in the network. 
Further conditions and constraints are defined in other Technical Specifications. 

4.3 Technique of description 

Layer 3 and its sub-layers are specified by: 

their service specification, see subclause 4.3.1; 
their protocol specification, see subclause 4.3.3; 
the specification of functions, see clause 5. 

4.3.1 Service description 

The services of signalling layer 3 and its sublayers are described in terms of: 

services provided to upper (sub-)layers at the service access points; 

services assumed from lower (sub-)layers at the service access points; 

Layer 3 and its supporting lower layers provide the Mobile Network Signalling (MNS) Service and User Data Transfer 
(UDT) Service (for GPRS services only) to the upper layers. 

The service provided/assumed at the service access points are described by means of abstract service primitives and 
parameters as recommended in CCITT Recommendation X.200. 

4.3.2 Abstract service primitives 

The abstract service primitives consist of requests, responses, indications and confirmations. The general syntax of a 
primitive is specified in GSM 04.0L 

4.3.3 Protocols and peer-to-peer communication 

By use of the services provided by lower (sub-)layers, peer entities in a (sub-)layer in the MS and the network exchange 
information. Exchange of information between two peer entities is performed according to the corresponding (sub-)layer 
protocols. A protocol is a set of rules and formats by which the information (control information and user data) is 
exchanged between the two peers. The information is exchanged by use of messages which are defined in the protocol. 
(Therefore, the messages are also called Protocol Data Units, PDUs). 

There are several protocols of the RR sublayer, one protocol of the LLC sublayer, three protocols of the MM sublayer, 
and several protocols of the CM sublayer. For each functional block of the CM sublayer as defined in subclause 4. 1 
there is one protocol. The CM protocols are specified in the Technical Specifications identified in subclause 4.3.4. 

In the model used in the present document, there is: 

1) for non-GPRS services: 

one RR sub-layer entity in the MS and one RR sub-layer entity in the network; 

one MM sub-layer entity in the MS and one MM sub-layer entity in the network; 
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for each functional block of the CM sublayer as defined in subclause 4. 1 which is supported in the MS (in the 
network), there are, depending on the protocol, one or more entities in the MS (in the network). Two different 
entities of the same functional block in the MS (in the network) are called parallel entities. The entities of the 
same functional block in the MS correspond in a one-to-one relation to the entities of the functional block in the 
network. The corresponding entities are called peer entities. 

2) for GPRS services supporting Class C MSs : 

one RR sublayer entity (RR) in the MS and one RR sublayer entity in the network; 

six LLC sublayer entities (QoSl-QoS4, signalling, SMS) in the MS and six LLC sublayer entities in the network; 

- one or more MM sublayer entities (GMM and/or 1-n GMM-AA) in the MS and one MM sublayer entity in the 
network (GMM or GMM-AA, i.e. the network don't know if several MM sublayer entities belong to the same MS 
or not); 

one SM entity in the MS's CM sublayer and one SM sublayer entity in the network's CM sublayer; 

one or more GSMS functional blocks in the CM sublayer if supported.: 

3) for non-GPRS and GPRS services supporting Class A and Class B MSs : 

two RR sublayer entities (RR) in the MS and two RR sublayer entities in the network; 

six LLC sublayer entities (QoSl-QoS4, signalling, SMS) in the MS and six LLC sublayer entities in the network; 

- two or more MM sublayer entities (GMM + MM or 1-n GMM-AA + MM or GMM + 1-n GMM-AA + MM) in 
the MS and one or two MM sublayer entity in the network (GMM + MM or GMM-AA); 

one SM entity in the MS's CM sublayer and one SM entity in the network's CM sublayer; 

for each functional block of the CM sublayer as defined in subclause 4. 1 which is supported in the MS (in the 
network), there are, depending on the protocol, one or more entities in the MS (in the network). Two different 
entities of the same functional block in the MS (in the network) are called parallel entities. The entities of the 
same functional block in the MS correspond in a one-to-one relation to the entities of the functional block in the 
network. The corresponding entities are called peer entities. 

As each sub-layer entity is specified by one and only one protocol, it is also called a protocol entity or protocol control 
entity. 

For GPRS-services supporting Class A and Class B MSs, the MM entities of the MM-sublayer are able to exchange 
information by means of GMM PDUs as well as MM PDU's. This means if a mobile is GPRS attached, non-GPRS 
mobility management procedures may make use of GRPS mobility management messages. 

When two peer protocol entities exchange PDUs, a transaction is said to be established (or: to be active; or: to exist). It 
depends from the protocol when exactly a protocol entity considers the transaction to be active, normally this is the case. 

from the moment when it has passed the first suitable message to lower (sub-) layers or received the first suitable 
message from its peer entity. 

up to the moment when it has released the transaction. 

4.3.4 Contents of layer 3 related Technical Specifications 

The Radio Resource (RR) management protocol is defined in GSM 04.08: 

- the Mobility Management (MM) protocol is defined in GSM 04.08; 

- the Session Management (SM) protocol is defined in GSM 04.08; 

- the Call Control (CC) protocol is defined in GSM 04.08; 

- the Supplementary Services (SS) protocol is defined in GSM 04. 10, GSM 04.8x and GSM 04.9x; 

- the Short Message Service (SMS) protocol is defined in GSM 04. 1 1 ; 
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- the Group Call Control (GCC) protocol is defined in GSM 04.68; 

- the protocols for Packet Data on SignaUing channels (PDS), PDSS 1 and PDSS2, are defined in GSM 04.63; 

- the Logical Link Control (LLC) protocol is defined in GSM 04.64; 

- the GPRS Radio Resource (GRR) protocol is defined in GSM 04.60 and GSM 04.08. 



5 Structure of layer 3 functions 

5.1 Basic groups of functions 

Most functions of layer 3 and its sub-layers are described by the service specifications and protocol specifications of 
the (sub-)layers. 

These functions are in the model realised by protocol control entities, see subclause 4.3.3. 

In addition, routing functions are contained in layer 3 which are related to the transport of messages, e.g. multiplexing 
and splitting. These routing functions are defined in the Radio Resource Management and Mobility Management 
sub-layers. 

1) They have the task to pass the messages from upper (sub-)layers to lower (sub-)layers. 

2) They also have the task to pass messages provided by lower (sub-layers) to the appropriate sub-layer and, if 
applicable, entity. 

The routing functions with task 2 make use of the protocol discriminator (PD) which is part of the message header. 

A CM sublayer protocol may also define a transaction identifier (Tl) as a part of the message header. This is at least the 
case if there are parallel entities of the same functional block, see subclause 4.3.3. If it is a part of a message, the TI is 
also used by the routing functions. 

The MM-sublayer routing function passes the messages of the CM entities as well as of the MM, GMM and 
GMM-AA entities of its own sublayer to the service access point of RR, GRR or LLC. Furthermore it 
multiplexes them in case of parallel transactions. 

The routing function of Radio Resource Management distributes the messages to be sent according to their 
message type and protocol discriminator (PD), to the actual channel configuration, and, if applicable, to further 
information received from upper sub-layers to the appropriate service access point of layer 2 (identified by S API 
and logical channel). Paging messages received from the PPCH are always routed to GMM, while paging 
messages received from the PCH are distributed to GMM or MM based on the temporary identifier (TMSI or 
TLL). 

The messages provided at the different service access points of layer 2 are distributed by the RR sublayer routing 
function according to their protocol discriminator (PD). Messages with a PD equal to RR are passed to the RR 
entity of the own sublayer, all other messages are passed to the MM sublayer at the service access point RR-S AP. 

The routing function of MM-sublayer passes Standard L3 messages according to the protocol discriminator (PD) 
and, if applicable, the transaction identifier (TI) or the PDP address towards the MM entity or towards the CM 
entities via the various MM-SAP's. GPRS L3 messages are routed to mobility management or session 
management according to the protocol discriminator. 

The routing function of LLC passes the messages according to the S APIs to the MM sublayer or to the SNDCP 
entities. 

The message (message header or other parts of the message) are neither changed nor removed by the RR routing 
function or MM routing function before passing it to the appropriate service access point. 
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5.2 Protocol architecture 

The protocol architecture is visuaHsed for each of the three models: 

Figure 5.1/GSM 0407 shows the protocol architecture for a MS not supporting the GPRS service, restricting the 
representation of CM sublayer protocols to three paradigmatic examples, CC, SS, and SMS. Note that the 
protocol stack for a class C GPRS service may be present in the MS, but it is not active simultaneously. 

Figure 5.2 shows the protocol architecture for a MS supporting the Class C GPRS service. (Note that the protocol 
stack for a circuit switched services may be present in the MS, but it is not active simultaneously) 

Figure 5.3 shows the protocol architecture for non-GPRS and GPRS-services supporting Class A and Class B 
MSs 



£75/ 



(GSM 04.07 version 6.5.1 Release 1997) 



19 



ETSI TS 100 939 V6.5.1 (1999-11) 



MOBILE 
NETWORK 
A SERVICE 



MMREG-SAP 




SAPI3 



Figure 5.1 : Protocol Architecture not supporting GPRS service MS side 
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Figure 5.2, Protocol architecture supporting GPRS class C MSs, MS - side 
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Figure 5.3/ GSM 04.07, Protocol architecture supporting GPRS class A and B MSs, MS - side 
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As shown in figure 5.1a hierarchy of 3 sublayers is defined: 

the RR sublayer provides services to the MM sublayer and utilizes the services of signalling layer 2; 

the MM sublayer provides common services to the entities of the Connection Management (CM) sublayer; 

the CM sublayer includes, among others, the CC, SS, and SMS entities, which are independent entities. 
Figure 5.2 defines four sublayers for GPRS services : 

the RR sublayer provides services to the MM and LLC sublayers; 

the LLC sublayer provides services to the MM sublayer, the SNDCP and GSMS entities and uses services of the 
RR sublayer; 

the MM sublayer provides services to the SM entities of the CM. The MM sublayer either includes (a.) one 
GMM entity for non-anonymous access or (b.) one or more GMM-AA entities for anonymous access or (c.) one 
GMM entity and one or more GMM-AA entities; 

the CM sublayer includes the SM and GSMS entities. The SM entity provides services to the SNDCP entity and 
uses services of the MM sublayer. The GSMS entity is identical to the SMS entity for non-GPRS services except 
it uses the services from the LLC sublayer 

Figure 5.3 defines four sublayers for non-GPRS and GPRS-services supporting Class A and Class B MSs : 

the RR sublayer provides services to the MM and LLC sublayers; 

the LLC sublayer provides services to the MM sublayer, the SNDCP and GSMS entities and uses services of the 
RR sublayer; 

the MM sublayer provides services to the SNDCP entity and to the entities of the Connection Management (CM) 
sublayer. In addition to the MM entity for non-GPRS services, the MM sublayer further includes either (a.) one 
GMM entity for non-anonymous access or (b) one or more GMM-AA entities for anonymous access or (c.) one 
GMM entity and one or more GMM-AA entities; 

the CM sublayer includes, among others, the CC, SS, GSMS and SM entities, which are independent entities. 

The SM entity provides services to the SNDCP entity and uses services of the MM sublayer. 
The GSMS entity is an extension of the SMS entity for non-GPRS services. For message transfer it uses the 
services both from the LLC sublayer and the MM entity of the MM sublayer. Furthermore it retrieves from the 
MM entity information about which transport service to use. 



6 Services provided by signalling layer 3 at the MS side 

The different classes of services provided by signalling layer 3 at the MS side are accessible at the following service 
access points: 

- registration services at the MMREG-SAP or GMMREG-SAP; 

Call Control services for normal and emergency calls including call related Supplementary Services Support 
services at the MNCC-SAP; 

- Short Message Services Support services at the MNSMS-SAP; 

Call independent Supplementary Services Support services at the MNSS-SAP; 

other services corresponding to further functional blocks of the CM sublayer at the appropriate service access 
points. These services are not further described in this clause; 

- Session Management services at the SMREG-SAP and at the SNSM-SAP 

- Logical Link Control services at the QoSl-SAP, QoS2-SAP, QoS3-SAP and QoS4-SAP. 
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6.1 Registration services 

The registration services (location updating, IMSI attach/detach) are provided at the service access point MMREG-SAP. 
As opposed to all other MN-Services, these services are provided by and can be directly accessed at the Mobility 
Management sublayer. 

6.1 .1 Service state diagram for IVIS not supporting GPRS service 

The registration services provided at the service access point MMREG-SAP are illustrated in the state of figure 6.1 
below. 

MMR-NREG-REQ 
IND 



MMR-REG-REQ 



MMR-REG-REQ 




MMR-REG-CNF 



^MMR-REG-ING 

Figure 6.1 : Registration services provided at IVIIVIREG-SAP - IVIS side 



6.1.2 Service primitives 



Table 6.1 : Primitives and Parameters at the MMREG-SAP - MS side 



PRIMITIVE 


PARAMETER 


REFERENCE 


MMR REG REQ 


IMSI 


6.1.2.1 


MMR REG CNF 


- 


6.1.2.2 


MMR NREG REQ 


- 


6.1.2.4 


MMR NREG IND 


cause 


6.1.2.5 



6.1.2.1 



MMR REG REQ 



Registration request, triggered by activation of the IMSI, e.g., by activation of the MS with inserted SIM, insertion of 
the SIM into the activated MS, pressing of a reset button. 

6.1.2.2 MMR_REG_CNF 

Registration confirmation. Indicates to the user that the MS is ready to start a transaction. 
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6.1.2.3 [reserved] 

6.1.2.4 MMR_NREG_REQ 

Request to cancel the registration, stimulated either by removing the SIM or automatically in the power off phase. 

6.1.2.5 MMR_NREGJND 

Indication that registration has been cancelled or that registration was not possible. Only emergency services are 
available to the user. 

6.2 Call Control services 

The Call Control services are provided by multiple CC entities at the service access point MNCC-SAP. 
The Call Control service class consists of the following services: 

Mobile originated and Mobile terminated call establishment for normal calls; 

Mobile originated call establishment for emergency calls; 

call maintaining; 

call termination; 

call related Supplementary Services Support. 

6.2.1 Service state diagram 

The Call Control services provided at the service access point MNCC-SAP are illustrated in the state diagram of 
figure 6.2. 
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Figure 6.2: Service graph of Call Control entity - MS side (page 1 of 2) 
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Figure 6.2: Service graphi of Call Control entity - lUIS side Active state (page 2 of 2) 
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6.2.2 Service primitives 



Table 6.2: Primitives and parameters at MNCC-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


MNCC_SETUP_REQ 


SETUP or EMERGENCY SETUP 


6.2.2.1 


MNCC_SETUP_IND 


SETUP 


6.2.2.2 


MNCC_SETUP_RSP 


CONNECT 


6.2.2.3 


MNCC_SETUP_CNF 


CONNECT 


6.2.2.4 


MNCC_SETUP_COMPLETE_REQ 


- 


6.2.2.5 


MNCC_SETUP_COMPLETE_IND 


- 


6.2.2.6 


MNCC_REJ_REQ 


RELEASE COMPLETE 


6.2.2.7 


MNCC_REJ_IND 


cause 


6.2.2.8 


MNCC_CALL_CONF_REQ 


CALL CONFIRMED 


6.2.2.9 


MNCC_CALL PROC_IND 


CALL PROCEEDING 


6.2.2.10 


MNCC_PROGRESS_IND 


PROGRESS 


6.2.2.11 


MNCC_ALERT_REQ 


ALERTING 


6.2.2.12 


MNCC_ALERT_IND 


ALERTING 


6.2.2.13 


MNCC_NOTIFY_REQ 


NOTIFY 


6.2.2.14 


MNCC_NOTIFY_IND 


NOTIFY 


6.2.2.15 


MNCC_DISC_REQ 


DISCONNECT 


6.2.2.16 


MNCC_DISC_IND 


DISCONNECT 


6.2.2.17 


MNCC_REL_REQ 


RELEASE 


6.2.2.18 


MNCC_REL_IND 


RELEASE 


6.2.2.19 


MNCC_REL_CNF 


RELEASE or RELEASE COMPLETE 


6.2.2.20 


MNCC_FACILITY_REQ 


facility 


6.2.2.21 


MNCC_FACILITY_IND 


facility 


6.2.2.22 


MNCC_START_DTMF_REQ 


START DTMF 


6.2.2.23 


MNCC_START_DTMF_CNF 


START DTMF ACK or START DTMF REJ 


6.2.2.24 


MNCC_STOP_DTMF_REQ 


STOP DTMF 


6.2.2.25 


MNCC_STOP_DTMF_CNF 


STOP DTMF ACK 


6.2.2.26 


MNCC_MODIFY_REQ 


MODIFY 


6.2.2.27 


MNCC_MODIFY_IND 


MODIFY 


6.2.2.28 


MNCC_MODIFY_RES 


MODIFY COMPLETE 


6.2.2.29 


MNCC_MODIFY_CNF 


MODIFY COMPLETE 


6.2.2.30 


MNCC_SYNC_IND 


cause (res. ass., channel mode modify) 


6.2.2.31 



6.2.2.1 



MNCC SETUP REQ 



Request to send a SETUP or EMERGENCY SETUP message to initiate Mobile originating establishment of either a 
normal or an emergency call. 

6.2.2.2 MNCC_SETUPJND 

Receipt of a SETUP message, the Mobile terminated call establishment has been initiated. 
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6.2.2.3 MNCC_SETUP_RES 

Response to send a CONNECT message to indicate call acceptance by the Mobile terminated user; call control is 
requested to attach the user connection (if it is not yet attached). 

6.2.2.4 MNCC_SETUP_CNF 

Receipt of a CONNECT message, the Mobile originated call has been accepted by the remote called user. 

6.2.2.5 MNCC_SETUP_COMPL_REQ 

Request to send a CONNECT ACKNOWLEDGE message, the mobile originating call has been accepted. 

6.2.2.6 MNCC_SETUP_COMPLJND 

Receipt of a CONNECT ACKNOWLEDGE message, the Mobile terminated call establishment has been completed; for 
a data call, the user is informed that the user connection is attached. 

6.2.2.7 MNCC_REJ_REQ 

Request to reject a Mobile terminated call if the call is refused or if the call cannot be accepted, e.g., because of missing 
compatibility. 

6.2.2.8 MNCC_REJJND 

Indication that the Mobile originated call has been rejected, e.g. if the MM connection cannot be provided or if the call 
establishment initiation has been rejected by the network. 

6.2.2.9 MNCC_CALL_CONF_REQ 

Request to confirm a Mobile terminated call by sending a CALL CONFIRMED message. A bearer capability different 
from that given in MNCC_SETUP_IND may be offered to the remote calling user. 

6.2.2.10 MNCC_CALL_PROCJND 

Indication to the Mobile originating user that call establishment has been initiated in the Network and no more call 
establishment information will be accepted by the Network. 

6.2.2.11 MNCC_PROGRESSJND 

Indication to the Mobile user that a PROGRESS message or a message containing a progress IE has been received, e.g., 
because the call is progressing in the PLMN/ISDN environment, or because the call has left the PLMN/ISDN 
environment, or because in-band tones/announcement are available. 

6.2.2.12 MNCC_ALERT_REQ 

Request to send an ALERTING message from the called Mobile user to the remote calling user to indicate that user 
alerting has been initiated. 

6.2.2.13 MNCC_ALERTJND 

Indication of the receipt of an ALERTING message, alerting to the remote called user has been initiated. 

6.2.2.14 MNCC_NOTIFY_REQ 

Request to send information pertaining to a call, such as user suspended, to the Network by the Mobile user. 
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6.2.2.15 MNCC_NOTIFYJND 

Indication to the Mobile user that information pertaining to a call, such as remote user suspended, has been received 
from the Network. 

6.2.2.16 MNCC_DISC_REQ 

Request to send a DISCONNECT message to the Network in order to clear the end-to-end connection. 

6.2.2.17 MNCC_DISCJND 

Indication of reception of a DISCONNECT message, by which the Network indicates that the end-to-end connection is 
cleared. 

6.2.2.18 MNCC_REL_REQ 

Request of the Mobile user to send a RELEASE message to inform the Network that the user intends to release the call 
reference and the corresponding MM connection so that the Network can release its MM connection and the 
correspondent call reference. 

6.2.2.19 MNCC_RELJND 

Indication to the Mobile originating or terminated user that a RELEASE message has been received and the Network 
intends to release its MM connection. The Mobile user is requested to release the call reference and the corresponding 
MM connection. 

6.2.2.20 MNCC_REL_CNF 

Confirmation of the Mobile user's request to release the MM connection and call reference in the Network. The Mobile 
user may release the call reference and the corresponding MM connection. 

6.2.2.21 MNCC_FACILITY_REQ 

Request to transport a facility IE for a call related supplementary service invocation. 

6.2.2.22 MNCC_FACILITYJND 

Indication that a facility IE for a call related supplementary service invocation has been received. 

6.2.2.23 MNCC_START_DTMF_REQ 

Request to send a START DTMF message in order to start a DTMF control operation. 

6.2.2.24 MNCC_START_DTMF_CNF 

Confirmation of the receipt of a START DTMF ACKNOWLEDGE or START DTMF REJECT message that the start 
of a DTMF control operation has been acknowledged or rejected. 

6.2.2.25 MNCC_STOP_DTMF_REQ 

Request to send a STOP DTMF message in order to stop a DTMF control operation. 

6.2.2.26 MNCC_STOP_DTMF_CNF 

Confirmation of the receipt of STOP DTMF ACKNOWLEDGE message, the DTMF control operation has been 
stopped. 
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6.2.2.27 MNCC_MODIFY_REQ 

Request to start Mobile originating in-call modification by sending a MODIFY message. 

6.2.2.28 MNCC_MODIFYJND 

RECEIPT OF A MODIFY message, a Mobile terminating in-call modification has been initiated. 

6.2.2.29 MNCC_MODIFY_RES 

Response to send a MODIFY COMPLETE message to indicate Mobile terminating in-call modification completion 
by the Mobile user. 

6.2.2.30 MNCC_MODIFY_CNF 

Receipt of a MODIFY COMPLETE message, the Mobile originating in-call modification has been completed. 

6.2.2.31 MNCC_SYNCJND 

Indication that a dedicated channel assignment has been performed (res. ass. = "resource assigned") and/or the channel 
mode has been changed. 

6.3 Call independent Supplementary Services Support 
6.3.1 Service state diagram 

The primitives provided by the call independent Supplementary Services Support entity and the transitions between 
permitted states are shown in figure 6.3. 



MNSS-END-REQ 
IND 



MNSS-BEGIN-REQ 
IND 




MNSS-END 
IND 



MNSS-FACILITY- 
IND 



STATES: 



IDLE - No SS signalling transaction pending 
CONN - SS signalling transaction established 



Figure 6.3: Service graph of the call independent Supplementary Services Support entity - MS side 
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6.3.2 Service primitives 



Table 6.3: Primitives and Parameters at MNSS-SAP - MS side 



PRIMITIVES 


PARAMETERS 

(Info elements of message) 


REFERENCE 


MNSS_BEGIN_REQ 


REGISTER 


6.3.2.1 


MNSS_BEGIN_IND 


REGISTER 


6.3.2.2 


MNSS_FACILITY_REQ 


FACILITY 


6.3.2.3 


MNSS_FACILITY_IND 


FACILITY 


6.3.2.4 


MNSS_END_REQ 


REL COMPLETE 


6.3.2.5 


MNSS_END_IND 


REL COMPLETE 


6.3.2.6 



6.3.2.1 



MNSS BEGIN REQ 



Request to send a REGISTER message in order to establish a signalling transaction for the provision of call independent 
supplementary services. The request for a call independent supplementary service invocation may be included. 



6.3.2.2 



MNSS BEGIN IND 



Receipt of a REGISTER message, a signalling transaction is established for the provision of call independent 
supplementary services after receipt of a REGISTER message. The indication of a supplementary service invocation 
may be included. 

6.3.2.3 MNSS_FAGILITY_REQ 

Request to send a FACILITY message for the provision of a call independent supplementary service invocation. 

6.3.2.4 MNSS_FACILITYJND 

Receipt of a FACILITY message for a call independent supplementary service invocation. 

6.3.2.5 MNSS_END_REQ 

Request to send a RELEASE COMPLETE message in order to release the signalling transaction. The request for 
transfer of a supplementary service facility may be included. 



6.3.2.6 



MNSS END IND 



Receipt of a RELEASE COMPLETE message, the signalling transaction has been released. The indication of a 
supplementary service facility may be included. 

6.4 Short Message Services Support 

The service provided by the CM sublayer to support the short message service are defined in 
GSM 04.11. 

6.5 Session Management Services for GPRS-Services 

Session Management services are provided at the SMREG-SAP and the SNSM-SAP for anonymous and non- 
anonymous access. The non-anonymous and anonymous access procedures for PDP context activation and PDP context 
deactivation are available at the SMREG-SAP. In addition there exists a PDP context modification for non-anonymous 
PDP contexts. 

Before SNDCP initiates any user data transfer, the PDP context activation procedure must be performed. 
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6.5.1 Session Management Services for SMREG-SAP 

Table 6.5: Primitives and Parameters at SMREG-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


SMREG-PDP-ACTIVATE-REQ 


PDP type, QoS, NSAPI, APN, Data mode 


6.5.1.1 


SMREG-PDP-ACTIVATE-CNF 


PDP type, PDP address, QoS, NSAPI, PDP config 
options 


6.5.1.2 


SMREG-PDP-ACTIVATE-REJ 


cause 


6.5.1.3 


SMREG-PDP-ACTIVATE-IND 


PDP type, QoS, NSAPI, APN 


6.5.1.4 


SMREG-PDP-DEACTIVATE-REQ 


NSAPI(s) 


6.5.1.5 


SMREG-PDP-DEACTIVATE-CNF 


NSAPI(s) 


6.5.1.6 


SMREG-PDP-DEACTIVATE-IND 


NSAPI(s) 


6.5.1.7 


SMREG-PDP-MODIFY-IND 


QoS(s), NSAPI(s) 


6.5.1.8 


SMREG-AA-PDP-ACTIVATE-REQ 


server address, QoS, NSAPI, Data mode 


6.5.1.9 


SMREG-AA-PDP-ACTIVATE-CNF 


QoS 


6.5.1.10 


SMREG-AA-PDP-ACTIVATE-REJ 


cause 


6.1.5.11 


SMREG-AA-PDP-DEACTIVATE-REQ 


NSAPI 


6.5.1.12 


SMREG-AA-PDP-DEACTIVATE-IND 


NSAPI 


6.5.1.13 



6.5.1.1 



SMREG-PDP-ACTIVATE-REQ 



The MS initiates a PDP context activation. SM is requested to send the ACTIVATE PDP CONTEXT REQUEST 

message to the network. The PDP context is pending activation. 



6.5.1.2 



SMREG-PDP-ACTIVATE-CNF 



The MS initiated PDP context activation succeeded. The network confirmed the PDP context activation, i.e. the 
ACTIVATE PDP CONTEXT ACCEPT message was received from the network. Then SM has ordered SNDCP to 
establish the needed LLC links. The PDP context is active. 



6.5.1.3 



SMREG-PDP-ACTIVATE-REJ 



The PDP context activation failed, the PDP context is not activated. One reason for failure is that the network rejected 
the activation attempt, which means the ACTIVATE PDP CONTEXT FAILURE message was received. Another reason 
is e.g. that it was not possible to establish the needed LLC links. 



6.5.1.4 



SMREG-PDP-ACTIVATE-IND 



The network asked for a PDP context activation. The REQUEST PDP CONTEXT ACTIVATION message was 
received from the network. The MS reacts either by initiating a new PDP context activation or by rejecting the network's 
request. 
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6.5.1.5 SMREG-PDP-DEACTIVATE-REQ 

The MS initiates a PDP context deactivation: SM is requested to send a DEACTIVATE PDP CONTEXT REQUEST 
message to the network. The PDP context is pending deactivation. 

6.5.1.6 SMREG-PDP-DEACTIVATE-CNF 

The MS initiated PDP context deactivation has been done. The network confirmed the PDP context activation, i.e. the 
ACTIVATE PDP CONTEXT ACCEPT message was received from the network. Then SM has ordered SNDCP to 
locally release not further needed LLC links. The PDP context has been deactivated. 

6.5.1.7 SMREG-PDP-DEACTIVATE-IND 

A network initiated a PDP context deactivation has been performed. The DEACTIVATE PDP CONTEXT REQUEST 
message has been received from the network. The MS has acknowledged with the DEACIVATE PDP CONTEXT 
ACCEPT message. The PDP context has been deactivated, Not further needed LLC links were locally released, 

6.5.1.8 SMREG-PDP-MODIFY-IND 

A network initiated a PDP context modification has been performed. The MODIFY PDP CONTEXT REQUEST 
message has been received from the network. The modification has been acknowledged by sending the MODIFY PDP 
CONTEXT ACCEPT message. One or several PDP contexts have been modified. LLC links are adjusted. 

6.5.1 .9 SMREG-AA-PDP-AGTIVATE-REQ 

The MS initiates an anonymous PDP context activation. SM is requested to send the ACTIVATE AA PDP REQUEST 
message to the network. The anonymous PDP context is pending activation. 

6.5.1 .10 SMREG-AA-PDP-AGTIVATE-GNF 

The MS initiated anonymous PDP context activation succeeded. The network confirmed the PDP context activation, i.e. 
the ACTIVATE AA PDP CONTEXT ACCEPT message was received from the network. Then SM has ordered SNDCP 
to establish the needed LLC links. The anonymous PDP context is active. 

6.5.1 .1 1 SMREG-AA-PDP-AGTIVATE-REJ 

The PDP context activation failed, the PDP context is not activated. One reason for failure is that the network rejected 
the activation attempt, which means the AA ACTIVATE PDP CONTEXT FAILURE message was received. Another 
reason is e.g. that it was not possible to establish the needed LLC links. 

6.5.1 .12 SMREG-AA-PDP-DEAGTIVATE-REQ 

The MS initiates the anonymous PDP context deactivation: 

6.5.1 .13 SMREG-AA-PDP-DEAGTIVATE-IND 

The MS anonymous PDP context deactivation has been performed. For example the MS's ready timer has expired, or 
the MS has left the routing area. Also the network may have requested deactivation, which means a DEACTIVATE AA 
PDP CONTEXT REQUEST message was received from the network. 

The session management services provided at the service access point SMREG-SAP are illustrated in the state machines 
of figure 6.4 and 6.5 below. Note, that the state machine describes only one PDP context within the SM entity. 
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SMREG-PDP-ACTIVATE-REQ 




SMREG-PDP-DEACTIVATE-REQ 
SMREG-PDP-DEACTIVATE-IND 



SMREG-PDP-MODIFY-IND 



Figure 6.4: Session IVIanagement service states at the SIVIREG-SAP for GPRS non-anonymous FDR 

context handling - MS side 



SMREG-AA-PDP- 
^CXrVATE-REQ 



SMREG-AA-PDP- 

DEACTIVATE-IND 

SMREG-AA-PDP- 
DEACTIVATE-REQ 




SMREG-AA-PDP- 
ACTIVATE-CNF 



Figure 6.5:Session management services states at SMREG-SAP for GPRS anonymous services - MS 

side 
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6.5.2 Session Management Services for SNSM-SAP 



6.5.2.1 



Service primitives 



This section is informative, the service primitives are defined in GSM 04.65 [12]. They are included here to provide a 
complete overview of the radio interface protocol architecture. 

Table 6.5.2: Service primitives and parameters at SNSM-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


SNSM-ACTIVATE-IND 


NSAPl, QoS, SAPI 


6.5.2.1.1 


SNSM-ACTIVATE-RSP 


- 


6.5.2.1.2 


SNSM-DEACTIVATE-IND 


NSAPl 


6.5.2.1.3 


SNSM-DEACTIVATE-RSP 


- 


6.5.2.1.4 


SNSM-MODIFY-IND 


NSAPl, QoS, SAPI 


6.5.2.1.5 


SNSM-MODIFY-RSP 


- 


6.5.2.1.6 


SNSM-STATUS-REQ 


- 


6.5.2.1.7 



6.5.2.1.1 



SNSM-ACTIVATE-IND 



Indication used by the SM entity to inform the SNDCP entity that an NSAPl has been activated for data transfer. It also 
informs the SNDCP entity about the negotiated QoS profile and the SAPI assigned for this NSAPL The request is sent 
by SM towards SNDCP during an ongoing PDP context activation procedure. 



6.5.2.1.2 



SNSM-ACTIVATE-RSP 



Response used by the SNDCP entity to inform the SM entity that the indicated NSAPl is now in use and that the 
acknowledged peer-to-peer LLC operation for the indicated SAPI is established, if necessary. 



6.5.2.1.3 



SNSM-DEACTIVATE-IND 



Indication used by the SM entity to inform the SNDCP entity that an NSAPl has been deallocated and cannot be used by 
the SNDCP entity anymore. The request is sent by SM towards SNDCP during an ongoing MS initiated as well as 
network initiated PDP context activation procedure. 



6.5.2.1.4 



SNSM-DEACTIVATE-RSP 



Response used by the SNDCP entity to inform the SM entity that the NSAPl indicated is no longer in use and that the 
acknowledged peer-to-peer LLC operation for the associated SAPI is released, if necessary. 



6.5.2.1.5 



SNSM-MODIFY-IND 



Indication used by the SM entity to trigger change of the QoS for an NSAPl and indication of the SAPI to be used. The 
request is sent by SM towards SNDCP during an ongoing PDP context modification procedure. 



6.5.2.1.6 



SNSM-MODIFY-RSP 



Response used by the SNDCP entity to inform the SM entity that the indicated NSAPl and QoS profile are now in use 
and the acknowledged peer-to-peer LLC operations for the appropriate SAPls are established and/or released, if 

necessary. 
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6.5.2.1.7 



SNSM-STATUS-REQ 



This primitive is used by the SNDCP entity to inform the SM entity that SNDCP cannot continue its operation due to 
errors at the LLC layer (as indicated with LL-Release. indication) or at the SNDCP layer. The Cause parameter indicates 
the cause of the error. 

6.6 Registration Services for GPRS-Services 

The attach/detach procedures comprise the registration services which are provided at the GMMREG-SAP for non- 
anonymous access. 

It shall be noted, that the registration services for mobiles of class A or B may depend on the service states for GPRS 
and non-GPRS services. Therefore the internal access points MMCOORD and the GMMCOORD ( see figure 5.3) are 
used by GMM and MM to inform each other about the relevant conditions. No service primitives between the entities 
within the same sublayer, i.e. the MM sublayer, are defined in 04.07. The Mobility Management for class A and B 
mobiles is further specified in 04.08. 

6.6.1 Registration Services for GMMREG-SAP 

Table 6.6.1 : Service primitives and parameters at GMMREG-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GMMREG-ATTACH-REQ 


attach-type, READY-timer, STANDBY-timer 


6.6.1.1 


GMMREG-ATTACH-CNF 


PLMNs MT-caps, attach-type. 


6.6.1.2 


GMMREG-ATTACH-REJ 


cause 


6.6.1.3 


GMMREG-DETACH-REQ 


detach-type, power-off/normal-detach 


6.6.1.4 


GMMREG-DETACH-CNF 


detach-type 


6.6.1.5 


GMMREG-DETACH-IND 


detach-type 


6.6.1.6 



6.6.1.1 



GMMREG-ATTACH-REQ 



MS initiates the GPRS and/or IMSI attach. GMM is requested to send an ATTACH REQUEST message to the network. 
The attachment is registration pending in the MS. 



6.6.1.2 



GMMREG-ATTACH-CNF 



The attach (either GPRS-attach or IMSI-attach or both) was successful. The network confirmed the attach, i.e. the 
ATTACH ACCEPT message was received by the MS. The LLC and RR sublayer will be informed by GMM about the 
TLLI to be used. 



6.6.1.3 



GMMREG-ATTACH-REJ 



The attach (either GPRS-attach or IMSI-attach or both) has failed. The network rejected the attach attempt, i.e. the 
message ATTACH REJECT was received from the network. 



6.6.1.4 



GMMREG-DETACH-REQ 



MS initiates GPRS and/or IMSI detach: GMM is requested to send a DETACH REQUEST message, the detach 
procedure is initiated. In case of MS initiated detach at power-off, the procedure is terminated in the MS after sending 
the DETACH REQUEST message. 
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6.6.1.5 



GMMREG-DETACH-CNF 



The MS initiated detach (either GPRS-attach or IMSI-attach or both) has been completed. 

The network confirmed the detach, i.e. the message DETACH ACCEPT was received from the network. This finahses 

the detach procedure (normal, not at power off). Any PDP context possibly activated before is deactivated. 



6.6.1.6 



GMMREG-DETACH-IND 



A network initiated detach has been performed. Or the detach has been performed locally due to expiration of the 
standby timer or a failed routing area update. In the first case the DETACH REQUEST message was from the network. 
Any PDP context possibly activated before is deactivated. 

The registration services provided at the service access point GMMREG-SAP are illustrated in the state machine of 
figure 6.6 below. Note, that in state registered the MS may be suspended from GPRS mobility management due to an 
ongoing CS connection. The registration procedure Routing Area Updating, which is not provided at the GMMREG- 
SAP, is not visible within the diagram. 



IDLE 



GMMREG- y^y^ 




-^ ^^ 




ATTACH-REQ ^^^^ 






\ GMMREG-DETACH-CFN 


y'^y^ GMMREG- 






^^^ 


y^y^ ATTACH-REJ 






^^^ 


REGISTI^^ 




GMMREG-DETACH 


/de- 


TION PEND/ 




-IND 


( REGISTRA 


--—^^--^ 




GMMREG-DETACH 


\TION PENJ 


^\ 




-REQ (power oH) 


^^ 


GMMREG ATTACH-CFN^^^ 


^REG 


ISTERED ) 


^^^ GMMREG-DETACH-REQ 
(not power oft) 



Figure 6.6: Registration services states at GIVIIVIREG-SAP for GPRS non-anonymous attach and 

detach - IVIS side. 

6.7 Services provided to SNDCP entities by GPRS Logical Link 
Control services 

This section is informative, the service primitives are defined in GSM 04.64 [11]. They are included here to provide a 
complete overview of the radio interface protocol architecture. 

Logical Link Control services are provided at the QoSl-SAP - QoS4 SAP towards the SNDCP and at the LLSMS-SAP 
towards SMS. 
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6.7.1 Service state diagram for Q0SI -SAP, QoS2-SAP, QoS3-SAP and 
Q0S4-SAP 



LL-UNITDATA-REQ/IND 



LL-ESTABLISH-REQ 
LL-ESTABLISH-IND 



LL-RELEASE-CNF 




LL-RELEASE-REQ 



LL-ESTABLISH-CNF 
LL-ESTABLISH-RSP 



LL-UNITDATA-REQ/IND 
LL-DATA-REQ/CNF/IND 



Figure 6.7: States to establish and release ABM mode operation 
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6.7.2 Service primitives for Q0SI -SAP, QoS2-SAP, QoS3-SAP and 
Q0S4-SAP 

Table 6.7.2: Service primitives and parameters at Q0SI to QoS4 - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


LL-ESTABLISH-REQ 


TLLI, SNDCP requested parameters (XID) 


6.7.2.1 


LL-ESTABLISH-CNF 


TLLI, SNDCP negotiated parameters (XID) 


6.7.2.2 


LL-ESTABLISH-IND 


TLLI, SNDCP requested parameters (XID), N201 


6.7.2.3 


LL-ESTABLISH-RSP 


TLLI, SNDCP negotiated parameters (XID) 


6.7.2.4 


LL-RELEASE-REQ 


TLLI 


6.7.2.5 


LL-RELEASE-CFN 


TLLI 


6.7.2.6 


LL-RELEASE-IND 


TLLI 


6.7.2.7 


LL-XID-REQ 


TLLI, SNDCP requested parameters (XID) 


6.7.2.8 


LL-XID-IND 


TLLI, SNDCP requested parameters (XID), N201 


6.7.2.9 


LL-XID-RSP 


TLLI, SNDCP negotiated parameters (XID) 


6.7.2.10 


LL-XID-CNF 


TLLI, SNDCP negotiated parameters (XID), N201 


6.7.2.11 


LL-DATA-REQ 


TLLI, N-PDU, local reference 


6.7.2.12 


LL-DATA-CNF 


TLLI, local reference 


6.7.2.13 


LL-DATA-IND 


TLLI, N-PDU 


6.7.2.14 


LL-UNITDATA-REQ 


TLLI, N-PDU, protect, cipher 


6.7.2.15 


LL-UNITDATA-IND 


TLLI, N-PDU 


6.7.2.16 


LL-STATUS-IND 


TLLI, cause 


6.7.2.17 



6.7.2.1 LL-ESTABLISH-REQ 

A LLC SABM frame will be sent to establish the LLC ABM mode. 

6.7.2.2 LL-ESTABLISH-CNF 

A LLC UA frame is received, the LLC ABM mode has been established. 

6.7.2.3 LL-ESTABLISH-IND 

A LLC SABM frame is received. 

6.7.2.4 LL-ESTABLISH-RSP 

A LLC UA frame will be sent, the ABM mode is established. 
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6.7.2.5 LL-RELEASE-REQ 

A LLC DISC frame will be sent to change to LLC ADM mode 

6.7.2.6 LL-RELEASE-CNF 

The LLC link has been disconnected, LLC is in ADM mode. 

6.7.2.7 LL-RELEASE-IND 

LLC is in idle mode. 

6.7.2.8 LL-XID-REQ 

An LLC XID frame will be sent. 

6.7.2.9 LL-XID-IND 

An LLC XID frame has been received. 

6.7.2.10 LL-XID-RSP 

An LLC XID frame will be sent as a response to a received XID frame. 

6.7.2.11 LL-XID-CNF 

An LLC XID frame has been received as a response to a sent XID frame. 

6.7.2.12 LL-DATA-REQ 

An LLC I frame will be sent to the peer entity. 

6.7.2.13 LL-DATA-CNF 

Successful reception of an LLC I frame has been acknowledged by the peer entity. 

6.7.2.14 LL-DATA-IND 

An LLC I frame has been received from the peer entity. 

6.7.2.15 LL-UNITDATA-REQ 

An LLC UI frame will be sent to the peer entity. 

6.7.2.16 LL-UNITDATA-IND 

An LLC UI frame has been received from the peer entity. 

6.7.2.17 LL-STATUS-IND 

Indication used by LLC to transfer LLC failures to the SNDCP sublayer. The failure may also be caused due to errors at 
the RLC/MAC layer. 
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7 Services provided by signalling layer 3 on the 

Network side 

In this clause, the services provided by signalHng layer 3 on the network side are described which belong to the CM 
sub-layer functional blocks of CC, SMS, and SS. The services corresponding to further functional blocks of the CM 
sublayer are not further described in this clause. 

7.1 Call control services 

The Call Control services are provided by multiple CC entities at the service access point MNCC-SAP. 
The Call Control service class consists of the following services: 

call establishment; 

call maintaining; 

call termination; 

call related Supplementary Services Support. 

7.1.1 Service state diagram 

The Call Control services provided at the service access point MNCC-SAP are illustrated in figure 7.1. 
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Figure 7.1 : (page 1 of 2) Service graph of Call Control entity - Network side 
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Figure 7.1 : (page 2 of 2) Service graph of Call Control entity - Network side 
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7.1.2 Service primitives 



Table 7.1 : Primitives and Parameters at MNCC-SAP - Network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


MNCC_SETUP_REQ 


SETUP incl. Mobile ID or EMERGENCY SETUP 


7.1.2.1 


MNCC_SETUP_IND 


SETUP 


7.1.2.2 


MNCC_SETUP_RSP 


CONNECT 


7.1.2.3 


MNCC_SETUP_CNF 


CONNECT 


7.1.2.4 


MNCC_SETUP_COMPL_REQ 


CONNECT ACKNOWLEDGE 


7.1.2.5 


MNCC_SETUP_COMPL_IND 


CONNECT ACKNOWLEDGE 


7.1.2.6 


MNCC_REJ_REQ 


RELEASE COMPLETE 


7.1.2.7 


MNCC_REJ_IND 


cause 


7.1.2.8 


MNCC_CALL_CONF_IND 


CALL CONFIRMED 


7.1.2.9 


MNCC_CALL PROC_REQ 


CALL PROCEEDING 


7.1.2.10 


MNCC_PROGRESS_REQ 


PROGRESS 


7.1.2.11 


MNCC_ALERT_REQ 


ALERTING 


7.1.2.12 


MNCC_ALERT_IND 


ALERTING 


7.1.2.13 


MNCC_NOTIFY_REQ 


NOTIFY 


7.1.2.14 


MNCC_NOTIFY_IND 


NOTIFY 


7.1.2.15 


MNCC_DISC_REQ 


DISCONNECT 


7.1.2.16 


MNCC_DISC_IND 


DISCONNECT 


7.1.2.17 


MNCC_REL_REQ 


RELEASE or DISCONNECT 


7.I.2.I8 


MNCC_REL_IND 


RELEASE 


7.1.2.19 


MNCC_REL_CNF 


RELEASE or RELEASE COMPLETE 


7.1.2.20 


MNCC_FACILITY_REQ 


facility 


7.1.2.21 


MNCC_FACILITY_IND 


facility 


7.1.2.22 


MNCC_START_DTMF_IND 


START DTMF 


7.1.2.23 


MNCC_START_DTMF_RSP 


START DTMF ACK or START DTMF REJ 


7.1.2.24 


MNCC_STOP_DTMF_IND 


STOP DTMF 


7.1.2.25 


MNCC_STOP_DTMF_RSP 


STOP DTMF ACK 


7.1.2.26 


MNCC_MODIFY_REQ 


MODIFY or BC-parameter 


7.1.2.27 


MNCC_MODIFY_IND 


BC-parameter 


7.1.2.28 


MNCC_MODIFY RES 


MODIFY COMPLETE 


7.1.2.29 


MNCC_MODIFY_CNF 


BC-parameter 


7.1.2.30 



7.1.2.1 MNCC_SETUP_REQ 

Request to send a SETUP message to initiate Mobile terminated establishment. 

7.1.2.2 MNCC_SETUPJND 

Receipt of a SETUP or EMERGENCY SETUP message, the Mobile originating call establishment has been initiated. 

7.1.2.3 MNCC_SETUP_RSP 

Response to send a CONNECT message to indicate call acceptance by the remote user. 
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7.1.2.4 MNCC_SETUP_CNF 

Receipt of a CONNECT message, the Mobile terminated call has been accepted. 

7.1.2.5 MNCC_SETUP_COMPL_REQ 

Request to send a CONNECT ACKNOWLEDGE message, the Mobile terminated call establishment has been 
completed. 

7.1.2.6 MNCC_SETUP_COMPLJND 

Indication of the receipt of a CONNECT ACKNOWLEDGE message, the Mobile originating call establishment has 
been completed. 

7.1.2.7 MNCC_REJ_REQ 

Reject the Mobile originated call establishment if the call cannot be accepted. 

7.1.2.8 MNCC_REJJND 

A Mobile terminated call was rejected by the MS, e.g. because of missing compatibility. 

7.1.2.9 MNCC_CALL_CONFJND 

Receipt of a CALL CONFIRMED message, the Mobile terminated call has been confirmed. A bearer capability 
different from that given in MNCC_SETUP_REQ may be offered to the remote calling user. 

7.1.2.10 MNCC_CALL_PROC_REQ 

Request to send a CALL PROCEEDING message to indicate to the Mobile originating user that call establishment has 
been initiated in the Network and no more call establishment information will be accepted. 

7.1.2.11 MNCC_PROGRESS_REQ 

Request to send a PROGRESS message or to piggy-back a progress IE in a suitable CC message in order to give the 
Mobile user information about the call , e.g., that the call is progressing in the PLMN/ISDN environment, or that the call 
has left the PLMN/ISDN environment, or that in-band tones/announcement are available. 

7.1.2.12 MNCC_ALERT_REQ 

Request to send an ALERTING message to indicate to the Mobile originating user that remote called user alerting has 
been initiated. 

7.1.2.13 MNCC_ALERTJND 

Receipt of an ALERTING message from the Mobile terminated user to be sent to the remote calling user to indicate that 
user alerting has been initiated. 

7.1.2.14 MNCC_NOTIFY_REQ 

Request to send information pertaining to a call, such as user suspended, to the Mobile originating or the Mobile 
terminated user. 

7.1.2.15 MNCC_NOTIFYJND 

Indication from the Mobile originating or Mobile terminated user of information pertaining to a call, such as remote user 
suspended. 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 46 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

7.1.2.16 MNCC_DISC_REQ 

Request to send a DISCONNECT message to the MS in order to clear the end-to-end connection. 

7.1.2.17 MNCC_DISCJND 

Receipt of a DISCONNECT message, the MS indicates that the end-to-end connection is cleared. 

7.1.2.18 MNCC_REL_REQ 

Request to send a RELEASE message to inform the MS that the network intends to release the MM connection and the 
correspondent call reference. 

7.1.2.19 MNCC_RELJND 

Receipt of a RELEASE message, the MS intends to release its MM connection and call reference. The Network is 
requested to release its call reference and MM connection. 

7.1.2.20 MNCC_REL_CNF 

The RELEASE COMPLETE message has been received, the MM connection in the MS has been released, the Network 
itself shall release its MM connection and the corresponding call reference. 

7.1.2.21 MNCC_FACILITY_REQ 

Request to transport a facility IE for call related supplementary service invocations. 

7.1.2.22 MNCC_FACILITYJND 

Indication that a facility IE for call related supplementary service invocations has been received. 

7.1.2.23 MNCC_START_DTMFJND 

Indicate the receipt of a START DTMF message in order to start a DTMF control operation. 

7.1.2.24 MNCC_START_DTMF_RSP 

Request to send a START DTMF ACKNOWLEDGE or START DTMF REJECT message in order to acknowledge or 
reject the start of a DTMF control operation. 

7.1.2.25 MNCC_STOP_DTMFJND 

Indicate the receipt of a STOP DTMF message in order to stop a DTMF control operation. 

7.1.2.26 MNCC_STOP_DTMF_RSP 

Request to send a STOP DTMF ACKNOWLEDGE message in order to acknowledge the completion of a DTMF 
control operation. 

7.1.2.27 MNCC_MODIFY_REQ 

Request to start the Mobile terminating in-call modification. 

7.1.2.28 MNCC_MODIFYJND 

Receipt of a MODIFY message, the Mobile originating in-call modification has been initiated. 
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7.1.2.29 



MNCC MODIFY RES 



Response to send a MODIFY COMPLETE to indicate to the Mobile user that the mobile originating in-call 
modification procedure has been completed. 

7.1.2.30 MNCC_MODIFY_CNF 

Confirmation that the Mobile terminating in-call modification has been completed. 

7.2 Call independent Supplementary Services Support 
7.2.1 Service state diagram 

The primitives provided by the call independent Supplementary Services Support entity and the transitions between 
permitted states are shown in the service graph of figure 7.2 below. 



, MNSS-END-REQ 
IND 



MNSS-BEGIN-IND 
REQ 




MNSS-END 
IND 



MNSS-FACILITY-REQ 
IND 

STATES: 

IDLE - No SS signalling transaction pending 

CONN - SS signalling transaction established 

Figure 7.2: Service graph of the call independent Supplementary Services 
Support entity - Network side 
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7.2.2 Service primitives 



Table 7.2: Primitives and Parameters at MNSS-SAP - Network side 



PRIMITIVES 


PARAMETERS 

(Info elements of message) 


REFERENCE 


MNSS_BEGIN_REQ 


REGISTER 


7.2.2.1 


MNSS_BEGIN_IND 


REGISTER 


7.2.2.2 


MNSS_FACILITY_REQ 


FACILITY 


7.2.2.3 


MNSS_FACILITY_IND 


FACILITY 


7.2.2.4 


MNSS_END_REQ 


RELEASE COMPLETE 


7.2.2.5 


MNSS_END_IND 


RELEASE COMPLETE 


7.2.2.6 



7.2.2.1 



MNSS BEGIN REQ 



Request to send a REGISTER message in order to establish a signalling transaction for the provision of call independent 
supplementary services. The request for a supplementary service invocation may be included. 



7.2.2.2 



MNSS BEGIN IND 



Receipt of a REGISTER message, a signalling transaction is established for the provision of call independent 
supplementary services. The indication of a supplementary service invocation may be included. 

7.2.2.3 MNSS_FAGILITY_REQ 

Request to send a FACILITY message for the provision of a call independent supplementary service facility. 

7.2.2.4 MNSS_FACILITYJND 

Receipt of a FACILITY message, a supplementary service facility has been requested. 

7.2.2.5 MNSS_END_REQ 

Request to send a RELEASE COMPLETE message in order to release the signalling transaction by sending a 
RELEASE COMPLETE message. The request for transfer of a supplementary service facility may be included. 



7.2.2.6 



MNSS END IND 



Indication that the signalling transaction has been released after receipt of a RELEASE COMPLETE message. The 
indication of a supplementary service facility may be included. 

7.3 Short Message Services Support 

The service provided by the CM sublayer to support the short message service are defined in GSM 04. 1 1 . 

7.4 Services provided to SNDCP and SMS entities by GPRS 
Logical Link Control services 

This section is informative, the service primitives are defined in GSM 04.64 [11]. They are included here to provide a 
complete overview of the radio interface protocol architecture. 

On the network side. Logical Link Control services are provided at the QoSl-SAP - QoS4 SAP towards the SNDCP and 
at the LLSMS-SAP towards SMS. 
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7.4.1 Service state diagram for Q0SI -SAP, QoS2-SAP, QoS3-SAP and 
Q0S4-SAP 

The service state diagram is identical on the network side is identical to the one shown in figure 6.7 for the mobile side. 

7.4.2 Service primitives for Q0SI -SAP, QoS2-SAP, QoS3-SAP and 
Q0S4-SAP 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


LL-ESTABLISH-REQ 


TLLI, SNDCP requested parameters (XID) 


7.4.2.1 


LL-ESTABLISH-CNF 


TLLI, SNDCP negotiated parameters (XID), N201 


7.4.2.2 


LL-ESTABLISH-IND 


TLLI, SNDCP requested parameters (XID), N201 


7.4.2.3 


LL-ESTABLISH-RSP 


TLLI, SNDCP negotiated parameters (XID) 


7.4.2.4 


LL-RELEASE-REQ 


TLLI 


7.4.2.5 


LL-RELEASE-CNF 


TLLI 


7.4.2.6 


LL-RELEASE-IND 


TLLI 


7.4.2.7 


LL-XID-REQ 


TLLI, SNDCP requested parameters (XID) 


7.4.2.8 


LL-XID-IND 


TLLI, SNDCP requested parameters (XID), N201 


7.4.2.9 


LL-XID-RSP 


TLLI, SNDCP negotiated parameters (XID) 


7.4.2.10 


LL-XID-CNF 


TLLI, SNDCP negotiated parameters (XID), N201 


7.4.2.11 


LL-DATA-REQ 


TLLI, N-PDU, local reference 


7.4.2.12 


LL-DATASENT-IND 


TLLI, local reference, V(S) 


7.4.2.13 


LL-DATA-CNF 


TLLI, local reference 


7.4.2.14 


LL-DATA-IND 


TLLI, N-PDU 


7.4.2.15 


LL-UNITDATA-REQ 


TLLI, N-PDU, protect, cipher 


7.4.2.16 


LL-UNITDATA-IND 


TLLI, N-PDU 


7.4.2.17 


LL-STATUS-IND 


TLLI, cause 


7.4.2.18 



7.4.2.1 LL-ESTABLISH-REQ 

A LLC SABM frame will be sent to establish the LLC ABM mode. 

7.4.2.2 LL-ESTABLISH-CNF 

A LLC UA frame is received, the LLC ABM mode has been established. 

7.4.2.3 LL-ESTABLISH-IND 

A LLC SABM frame is received. 
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7.4.2.4 LL-ESTABLISH-RSP 

A LLC UA frame will be sent, the ABM mode is established. 

7.4.2.5 LL-RELEASE-REQ 

A LLC DISC frame will be sent to change to LLC ADM mode. 

7.4.2.6 LL-RELEASE-CNF 

The LLC link has been disconnected, LLC is in ADM mode. 

7.4.2.7 LL-RELEASE-IND 

LLC is in idle mode. 

7.4.2.8 LL-XID-REQ 

An LLC XID frame will be sent. 

7.4.2.9 LL-XID-IND 

An LLC XID frame is received. 

7.4.2.10 LL-XID-RSP 

An LLC XID frame will be sent as a reply to a received XID frame. 

7.4.2.11 LL-XID-CNF 

An LLC XID frame has been received as a reply to a sent XID frame. 

7.4.2.12 LL-DATA-REQ 

An LLC I frame will be sent to the peer entity. 

7.4.2.13 LL-DATASENT-IND 

The sent LLC frame was sent with the V(S) indicated. 

7.4.2.14 LL-DATA-CNF 

Successful reception of an LLC I frame has been acknowledged by the peer entity. 

7.4.2.15 LL-DATA-IND 

An LLC I frame has been received form the peer entity. 

7.4.2.16 LL-UNITDATA-REQ 

An LLC UI frame will be sent to the peer entity. 

7.4.2.17 LL-UNITDATA-IND 

An LLC UI frame has been received from the peer entity. 
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7.4.2.18 



LL-STATUS-IND 



Indication used by LLC to transfer LLC failures to the SNDCP sublayer. The failure may also be caused due to errors at 
the RLC/MAC layer. 

7.5 Session Management Services for GPRS 

On the network side Session Management Services are provided only at the SNSM-SAP 

7.5.1 Session Management Services for SIVIREG-SAP 

Table 7.5.1 : Primitives and Parameters at SMREG-SAP - network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


SMREG-PDP-ACTIVATE-REQ 


PDP type, PDP address, QoS, NSAPI, APN, Data 
mode 


7.5.1.1 


SMREG-PDP-ACTIVATE-REJ 


cause 


7.5.1.2 


SMREG-PDP-DEACTIVATE-REQ 


NSAPI(s) 


7.5.1.3 


SMREG-PDP-DEACTIVATE-CNF 


NSAPI(s) 


7.5.1.4 


SMREG-PDP-MODIFY-REQ 


QoS(s), NSAPI(s) 


7.5.1.5 


SMREG PDP-MODIFY-CNF 


server address, QoS(s), NSAPI(s) 


7.5.1.6 


SMREG PDP-MODIFY-REJ 


server address, QoS(s), NSAPI(s) 


7.5.1.7 



7.5.1.1 



SMREG-PDP-ACTIVATE-REQ 



The network initiates a PDP context activation. SM is requested to send the ACTIVATE PDP CONTEXT REQUEST 
message to the MS. The PDP context is pending activation. The network expects that the MS continues with a normal 
MS initiated context activation. Therefore at the SMREG-SAP no confirmation is provided. 



7.5.1.2 



SMREG-PDP-ACTIVATE-REJ 



The network initiated PDP context activation failed. Either the ACTIVATE PDP CONTEXT FAILURE message was 
received from the MS, or lower layer failure or timer expiry caused abortion of the activation procedure. 



7.5.1.3 



SMREG-PDP-DEACTIVATE-REQ 



The network initiates a PDP context deactivation. SM is requested to send a DEACTIVATE PDP CONTEXT 
REQUEST message. The PDP context is pending deactivation. 



7.5.1.4 



SMREG-PDP-DEACTIVATE-CNF 



The network initiated PDP context activation has been concluded. The MS confirmed he PDP context activation, i.e. the 
DEACTIVATE PDP CONTEXT ACCEPT message was received. Then SM ordered SNDCP to locally release those 
LLC links not further needed by other PDP contexts. The PDP context is deactivated. 



7.5.1.5 



SMREG-PDP-MQDIFY-REQ 



The network initiates a modification of the PDP context. SM is requested to send a MODIFY PDP CONTEXT 
REQUEST message to the MS. The PDP context is pending modification. 
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7.5.1.6 



SMREG-PDP-MODIFY-CNF 



The PDP context modification has been concluded. The MS confirmed he PDP context modification, i.e. the MODIFY 
PDP CONTEXT ACCEPT message was received. Then SM ordered SNDCP to adjust LLC Hnks as required. The PDP 
context is modified. 



7.5.1.7 



SMREG-PDP-MODIFY-REJ 



The PDP context modification has been failed. Due to timer expiry or lower layer failure the modification procedure has 
been aborted. 

7.5.2 Session Management Services for SNSM-SAP 

Table 7.5.2: Primitives and Parameters at SNSM-SAP - network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


SNSM-ACTIVATE-IND 


TLLI, NSAPI, QoS, SAPI 


7.5.2.1 


SNSMM-ACTIVATE-RSP 


TLLI, 


7.5.2.2 


SNSM-DEACTIVATE-IND 


TLLI, NSAPI 


7.5.2.3 


SNSM-DEACTIVATE-RSP 


TLLI 


7.5.2.4 


SNSM-MODIFY-IND 


TLLI, NSAPI, QoS, SAPI 


7.5.2.5 


SNSM-MODIFY-RSP 


TLLI 


7.5.2.6 


SNSM-STATUS-REQ 


TLLI, NSAPI, Cause 


7.5.2.7 


SNSM-WINDOW-IND 


TLLI, NSAPI + MS's V(R)s 


7.5.2.8 



7.5.2.1 



SNSM-ACTIVATE-IND 



Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been activated for data transfer. It also 
informs the SNDCP entity about the negotiated QoS profile and the SAPI assigned for this NSAPI. The request is sent 
by SM towards SNDCP during an ongoing PDP context activation procedure. 



7.5.2.2 



SNSM-ACTIVATE-RSP 



Response used by the SNDCP entity to inform the SM entity that the indicated NSAPI is now in use and that the 
acknowledged peer-to-peer LLC operation for the indicated SAPI is established, if necessary. 



7.5.2.3 



SNSM-DEACTIVATE-IND 



Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been de-allocated and cannot be used 
by the SNDCP entity anymore. The request is sent by SM towards SNDCP during an ongoing PDP context activation 
procedure, or by SM in the old SGSN during an ongoing inter-SGSN routeing area update procedure. 



7.5.2.4 



SNSM-DEACTIVATE-RSP 



Response used by the SNDCP entity to inform the SM entity that the NSAPI indicated is no longer in use and that the 
acknowledged peer-to-peer LLC operation for the associated SAPI is released, if necessary. 
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7.5.2.5 SNSM-MODIFY-IND 

Indication used by the SM entity to trigger change of the QoS for an NS API and indication of the S API to be used. It is 
also used by the SM entity to inform the SNDCP entity that an NSAPI shall be created, together with the (re-)negotiated 
QoS profile and the SAPI assigned. The former is used during an ongoing PDP context modification procedure. The 
latter is used in the new SGSN during an ongoing inter-SGSN routeing area update procedure. 

7.5.2.6 SNSM-MODIFY-RSP 

Response used by the SNDCP entity to inform the SM entity that the indicated NSAPI and QoS profile are now in use 
and the acknowledged peer-to-peer LLC operations for the appropriate SAPIs are established and/or released, if 
necessary. 

7.5.2.7 SNSM-STATUS-REQ 

This primitive is used by the SNDCP entity to inform the SM entity that SNDCP cannot continue its operation due to 
errors at the LLC layer (as indicated with LL-Release. indication) or at the SNDCP layer. The Cause parameter indicates 
the cause of the error. 

7.5.2.8 SNSM-WINDOW-IND 

This primitive is used in case of inter SGSN routing area updating. The LLC frames confirmed by the MS are indicated 
to the SNDCP sublayer. The SNDCP sublayer will retransmit an N-PDU again if the MS has not confirmed all LLC 
PDUs that belong to the possibly segmented N-PDU. 

TCP/IP header and V.42bis data compression algorithms shall be reset before N-PDU transmission is resumed. 



8 Services assumed from signalling layers 1 and 2 

The services provided by layer 2 are defined in detail in GSM 04.05. A short summary is given below. 

In addition, layer 1 communicates directly with layer 3 for information transfer related to channel management and to 
measurement control. See section 8.5 below. 

8.1 Priority 

Messages from layer 3 can be sent with: 
no priority; 

i.e. the messages are sent in first-in-first-out order; 
priority; 
i.e. a message with this indication is sent as early as possible by layer 2. 

8.2 Unacknowledged information transfer 

Transfer of unacknowledged information using the primitives DL_UNIT_DATA_ REQUEST/INDICATION. 
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8.3 Acknowledged information transfer 

Transfer of information in multiframe acknowledged mode including: 

establishment of data link connection between L3 entities; 

transfer of information in acknowledged mode; 

release of the data link connection. 
The primitives associated with acknowledged information transfer are: 

- DL_ESTABLISH_REQUEST/INDICATION/CONFIRM for establishment of acknowledged mode; 

DL_DATA_REQUEST/INDICATION for requesting the transmission of a message unit and for indicating the 
reception of a message unit; 

- DL_SUSPEND_REQUEST/DL_RELEASE_CONFIRM for requesting and confirming the suspension of the 
acknowledged information transfer in the MS upon channel change; 

- DL_RESUME_REQUEST/DL_ESTABLISH_CONFIRM for requesting and confirming the resumption of the 
acknowledged information transfer in the MS after suspension at channel change; 

- DL_RELEASE_REQUEST/INDICATION/CONFIRM for the termination of acknowledged mode operation; 

DL_RECONNECT_REQUEST for requesting the re-establishment of acknowledged information transfer in the 
MS on the old channel after channel change failure. 

8.4 Random access 

The transmission/reception of a random access burst is controlled by the primitives 
DL_RANDOM_ACCESS_REQUEST/INDICATION/CONFIRM. 

8.5 Channel management and measurements 

The management of channels, i.e. their activation, deactivation, configuration, deconfiguration, through-connection and 
disconnection is controlled by the RR sublayer in layer 3. The measurements performed by the physical layer are also 
controlled by the RR sublayer of layer 3 and they are reported to layer 3. 

These functions use the primitives MPH_INFORMATION_REQUEST/INDICATION/CONFIRMATION. 

9 Interlayer service interfaces on the IVIS side 

In addition to the services described in this clause, the RR entity and MM entity also provide services to CM entities 
which don't belong to the functional blocks of CC, SMS, and SS. (For example, the RR entity provides service to Group 
Call and Broadcast Call entities.) These services are not further described in this clause. 

9.1 Services provided by the Radio Resource IVIanagement 
entity 

The Radio Resource Management (RR) sublayer provides a service to the Mobility Management entity (MM). 
The RR services are used for: 

establishing control channel connections; 

releasing control channel connections; 

control-data transfer. 
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The Radio Resource Management services are represented by the RR-service primitives. 

MS side Network side 



IVIobility 

IVIanagement 

sublayer 



Radio Resource 

Management 

sublayer 



A 



RR 
SAP 



RR-primitives 



RR sublayer peer- 
to-peer protocol 




Figure 9.1 : Services provided at RR-SAP - IVIS side 



9.1 .1 Service state diagram 



The primitives provided by the Radio Resource Management entity and the transition between permitted states are 
shown in figure 9.2. 
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Figure 9.2: Service graphi of tlie Radio Resource lUlanagement - IVIS side 
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9.1.2 Service primitives 



Table 9.1 : Primitives and parameters at the RR-SAP - MS side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


RR_EST_REQ 


Layer 3 message transferred in the SABM frame 


9 


L2.1 


RR_EST_IND 


- 


9 


L2.2 


RR_EST_CNF 


- 


9 


L2.3 


RR_REL_IND 


cause 


9 


L2.4 


RR_SYNC_IND 


cause (ciphering, res. ass., channel mode modify) 


9 


L2.5 


RR_DATA_REQ 


Layer 3 message 


9 


L2.6 


RR_DATA_IND 


Layer 3 message 


9 


L2.7 


RR_UNIT DATA_IND 


Layer 3 message 


9 


L2.8 


RR_ABORT_REQ 


cause 


9 


L2.9 


RR_ABORT_IND 


cause 


9 


L2.10 


RR_ACT_REQ 


reselection mode 


9 


L2.11 



9.1.2.1 



RR EST REQ 



Is used by the Mobility Management entity to request establishment of a Mobile originated RR connection. The request 
shall be given only in the IDLE state when the MS listens to the CCCH and the previously selected BCCH. 



9.1.2.2 



RR EST IND 



Indicates to the Mobility Management entity the establishment of a Mobile terminated RR connection. By this indication 
MM is informed that a transparent connection exists and RR is in the dedicated mode. 



9.1.2.3 



RR EST CNF 



Is used by RR to indicate the successful completion of a Mobile originated RR connection establishment. RR connection 
exists and RR is in the dedicated mode. 



9.1.2.4 



RR REL IND 



Is used by RR to indicate to the Mobility Management entity the release of a RR connection when RR has received a 
CHANNEL RELEASE from the Network and has triggered a normal release of the data link layer. It is also used to 
indicate that a requested RR connection cannot be established. In both cases, RR returns to IDLE mode. 



9.1.2.5 



RR SYNC IND 



Is used for synchronizing RR and the Mobility Management entity after the establishment of a Mobile originated or 
Mobile terminated RR connection. This indication is provided to MM in the following cases: 

ciphering has been started (ciphering); 

a traffic channel has been assigned (res. ass. = "resource assigned"); 

the channel mode has been modified (channel mode modify). 



9.1.2.6 



RR DATA REQ 



Is used by the Mobility Management entity to send control data to its peer entity on the Network side via an existing RR 
connection. 
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9.1.2.7 



RR DATA IND 



Is used by RR to indicate control-data, which has been received from its peer entity on the Network side via an existing 
RR connection. 



9.1.2.8 



RR UNIT DATA IND 



Is used by RR to provide MM with system info. The system info is received on the current BCCH if RR is in the IDLE 
state. If a RR connection has been established, the system info is received on the SACCH. 



9.1.2.9 



RR ABORT REQ 



Request to abort an existing RR connection or a RR connection in progress. The data link, if already established, shall 
be released by a normal release procedure (DISC/UA) initiated by the MS. This is the only way the MS can trigger the 
release of a RR connection in case of exceptional conditions. The RR returns to the IDLE state. 

9.1.2.10 RR_ABORTJND 

Indication that the RR connection has been aborted by a lower layer failure and RR has returned to the IDLE state. 

9.2 Services provided by the IVIobility IVIanagement entity 

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, the Supplementary 
Services Support (SS) entity and the Short Message Service Support (SMS) entity. 

The Mobility Management services primitives are discriminated by the MMCC, MMSS and MMSMS prefix. 
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Figure 9.3: Services provided at the IVIIVICC-SAP, IVIIVISS-SAP, IVIIVISIVIS-SAP - IVIS side 
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9.2.1 Service State diagram 



The primitives provided by the Mobility Management entity towards Call Control, call independent Supplementary 
Service Support and towards Short Messages Service Support and the transition between permitted states are illustrated 
in figure 9.4. 



MMXX-UNIT-DATA-IND 



MMXX-EST-REQ 



MMXX-REL- 
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MMXX-UNIT 
DATA-REQ 



MMXX-EST-CNF 
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(channel mode modify) 
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MMXX-DATA-REQ IND 
MMXX-UNIT-DATA-REQ IND 

NOTE 1 : MMCC-primitives only at MMCC-SAP. 

NOTE 2: The prefix MMXX is used for substitution of MMCC, MMSS or MMSMS. 

Figure 9.4: Service graph of the IVIobility IVIanagement entity - IVIS side 
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9.2.2 Service primitives 



Table 9.2: Primitives and Parameters at MMCC-SAP, MMSS-SAP or MMSMS-SAP - MS side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


MMXX_EST_REQ (see note 1) 


Parameters for the appropriate 
CM SERVICE REQUEST (if any) 


9.2.2.1 


MMXX_EST_IND (see note 1) 


First CM message 


9.2.2.2 


MMXX_EST_CNF (see note 1) 


- 


9.2.2.3 


MMXX_REL_REQ (see note 1) 


cause 


9.2.2.4 


MMXX_REL_IND (see note 1) 


cause 


9.2.2.5 


MMXX_DATA_REQ (see note 1) 


Layer 3 message 


9.2.2.6 


MMXX_DATA_IND (see note 1) 


Layer 3 message 


9.2.2.7 


MMXX_UNIT_DATA_REQ (see note 1) 


Layer 3 message 


9.2.2.8 


MMXX_UNIT_DATA_IND (see note 1) 


Layer 3 message 


9.2.2.9 


MMCC_SYNC_IND (see note 2) 


cause: res. ass 


9.2.2.10 


MMXX_REEST_REQ (see note 1) 




9.2.2.11 


MMXX_REEST_CNF (see note 1) 




9.2.2.12 


MMXX_ERR_IND (see note 1) 


cause 


9.2.2.13 


MMXX_PROMPT_IND (see note 1) 


- 


9.2.2.14 


MMXX_PROMPT_REJ (see note 1) 


- 


9.2.2.15 


NOTE 1 : MMXX is used as substitution for IVIIVICC, IVIIVISS or IVIIVISIVIS 
NOTE 2: Only at MMCC-SAP 



9.2.2.1 



MMXX EST REQ 



Request used by CC, SS and SMS respectively, to request establishment of a MM connection. Several MM connections 
may be provided in parallel to the requesting entities. The primitive may contain parameters which are relevant for the 
CM SERVICE REQUEST message, e.g. to distinguish a basic call from an emergency call. 



9.2.2.2 



MMXX EST IND 



Indication to CC, SS or SMS that a Mobile terminated MM connection has been established and the first message has 
been received from the respective peer entity. Several MM connections may be provided in parallel. If a MM connection 
already exists, a new MM connection using the same RR connection is indicated by this primitive if MM detects a 
message with a new combination of Protocol Discriminator (PD) and Transaction Identifier (TI). 



9.2.2.3 



MMXX EST CNF 



Successful confirmation of the MM connection establishment by the MM sublayer to be given to the appropriate entity 
which has requested the service. 



9.2.2.4 



MMXX REL REQ 



Used by CC, SS or SMS respectively, to request release of the MM connection. The corresponding PD/TI will be 
released and may be used for a new MM connection. 



9.2.2.5 



MMXX REL IND 



Indication of the release of an existing MM connection or a MM connection in progress. This primitive is used in 
exceptional cases to indicate that the MM connection cannot be established or kept any longer and PD/TI have been 
released. 
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9.2.2.6 MMXX_DATA_REQ 

Request used by the CC, SS or SMS entities for acknowledged control-data transmission. 

9.2.2.7 MMXX_DATAJND 

Indication used by MM to transfer the received acknowledged control-data to the CC, SS or SMS entities. 

9.2.2.8 MMXX_UNIT_DATA_REQ 

Request used by the CC, SS or SMS entities for unacknowledged control-data transmission. 

9.2.2.9 MMXX_UNIT_DATAJND 

Indication used by MM to transfer the received unacknowledged control-data to the CC, SS or SMS entities. 

9.2.2.10 MMCC_SYNCJND 

Indication that a dedicated channel assignment has been performed and/or the channel mode has been changed (only 
towards the CC entity). 

9.2.2.11 MMXX_REEST_REQ 

Request to establish a MM connection which has been interrupted by a lower layer failure. The interruption must have 
been indicated by MMXX_ERR_IND. 

9.2.2.12 MMXX_REEST_CNF 

Confirmation of the successful re-establishment of the MM connection. The MM connection will continue with PD/TI as 
it had before. 

9.2.2.13 MMXX_ERRJND 

Indication of a lower layer failure interrupting the MM connection. The PD/TI are still kept by MM. In case of parallel 
transactions this indication is passed to all CM entities for which a MM connection has been established. It is left to the 
decision of the appropriate CM entity to either request the re-establishment of the MM connection by 
MMXX_REEST_REQ or to release it by MMXX_REL_REQ. 

9.2.2.14 MMXX_PROMPTJND 

Indication given by MM to inform of the completion of the MM connection to the CC, SS or SMS entities for a mobile 
station which supports "Network Initiated MO CM Connection Request". 

9.2.2.15 MMXX_PROMPT_REJ 

Response to the MMXX_PROMPT_IND indication to the MM entity in a mobile station which supports "Network 
Initiated MO CM Connection Request" in case when it is impossible to establish the prompted CM connection e.g. due 
to lack of free transaction identifiers. 

9.3 Services provided by radio resource management entity for 
GPRS services 

This subclause is informative, the service primitives are defined in GSM 04.60 [10]. They are included here to provide a 
complete overview of the radio interface protocol architecture. 



£75/ 



(GSM 04.07 version 6.5.1 Release 1997) 



61 



ETSI TS 100 939 V6.5.1 (1999-11) 



9.3.1 Service primitives for GRR-SAP 

Table 9.3.1 : Primitives and parameters at GRR-SAP 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GRR-DATA-REQ 


LLC PDU, Priority, Cause 


9.3. LI 


GRR-DATA-IND 


LLC PDU 


9.3. L2 


GRR-UNITDATA-REQ 


LLC PDU, Priority 


9.3. L3 


GRR-UNITDATA-IND 


LLC PDU 


9.3. L4 


GRR-STATUS-IND 


cause 


9.3. L5 



9.3.1.1 



GRR-DATA-REQ 



Request used by the LL sublayer for acknowledged data transmission with a certain priority. Cause indicates if the GRR- 
DATA-REQ was triggered as an implicit page response. 

9.3.1.2 GRR-DATA-IND 

Indication used by RR to transfer received data to the LL sublayer. 

9.3.1.3 GRR-UNITDATA-REQ 

Request used by the LL sublayer for unacknowledged data transmission with a certain priority. 

9.3.1.4 GRR-UNITDATA-IND 

Indication used by RR to transfer received data to the LL sublayer. 

9.3.1.5 GRR-STATUS-IND 

Indication used by RR to transfer RLC/MAC failures to the LL sublayer. 

9.3.2 Service primitives for GMMRR-SAP 

Table 9.3.2: Primitives and Parameters at GMMRR-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other parameters) 


REFERENCE 


GMMRR-ASSIGN-REQ 


newTLLI 


9.3.2.1 


GMMRR-PAGE-IND 


TLLI 


9.3.2.2 



9.3.2.1 GMMRR-ASSIGN-REQ 

A new TLLI is assigned to the RR sublayer. 

9.3.2.2 GMMRR-PAGE-IND 

A RR-paging message has been received by the RR sublayer. 
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9.4 Services provided by the LLC entity for GPRS services 

This subclause is informative, the service primitives are defined in GSM 04.64 [11]. They are included here to provide a 
complete overview of the radio interface protocol architecture. 

9.4.1 Service primitives for LLGIVIIVI-SAP 

Table 9.4.1 : Primitives and parameters at LLGMM-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


LLGMM-ASSIGN-REQ 


oldTLLI, newTLLI, Kc, RAND, Ciphering Algorithm 


9.4.1.1 


LLGMM-TRIGGER-REQ 


Cause 


9.4.1.2 


LLGMM-TRIGGER-IND 


- 


9.4.1.3 


LLGMM-SUSPEND-REQ 


TLLl 


9.4.1.4 


LLGMM-RESUME-REQ 


TLLI 


9.4.1.5 


LLGMM-WINDOW-REQ 


TLLI, old SGSN's V(R) per SAPl 


9.4.1.6 


LLGMM-WINDOW-CNF 


TLLl, actual MS's LLC's V(R) per SAPI 


9.4.1.7 


LL-UNITDATA-REQ 


TLLI, GMM-PDU, protect, cipher 


9.4.1.8 


LL-UNITDATA-IND 


TLLl, GMM-PDU, cipher 


9.4.1.9 


LLGMM-STATUS-IND 


TLLl, cause 


9.4.1.10 



9.4.1.1 LLGMM-ASSIGN-REQ 

A new TLLl and/or a ciphering key and/or a ciphering algorithm is assigned to the LLC sublayer. 

9.4.1.2 LLGMM-TRIGGER-REQ 

Request to send an LLC PDU to the network. Cause indicates if the primitive is sent to trigger an implicit page response. 

9.4.1.3 LLGMM-TRIGGER-IND 

An LLC frame has been transmitted to the network. 

9.4.1.4 LLGMM-SUSPEND-REQ 

All LLC links in ABM mode will cease sending PDUs. GMM messages can still be sent and received. 

9.4.1.5 LLGMM-RESUME-REQ 

Normal LLC frame sending and reception is possible again. 

9.4.1.6 LLGMM-WINDQW-REQ 

Request for the MS's actual LLC's V(R)s. 
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9.4.1.7 LLGMM-WINDOW-CNF 

The actual LLC's V(R)s for each LLC link in ABM mode are transferred to GMM. 

9.4.1.8 LL-UNITDATA-REQ 

Request to send a GMM message in unacknowledged mode to the peer entity. 

9.4.1.9 LL-UNITDATA-IND 

A GMM message in unacknowledged mode has been received from the peer entity. 

9.4.1.10 LLGMM-STATUS-IND 

Indication used by LLC to transfer LLC failures to the GMM sublayer. The failure may also be caused due to errors at 
the RLC/MAC layer. 

9.4.2 Service primitives for LLSMS-SAP 

Table 9.4.2: Service primitives and parameters at LLSMS-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


LL-UNITDATA-REQ 


TLLI, SMS-CP-PDU, protect, cipher 


9.4.2.1 


LL-UNITDATA-IND 


TLLI, SMS-CP-PDU, 


9.4.2.2 



9.4.2.1 LL-UNITDATA-REQ 

An LLC UI frame will be sent to the peer entity 

9.4.2.2 LL-UNITDATA-IND 

An LLC UI frame has been received from the peer entity 



9.5 Registration Services provided for GPRS Services 
9.5.1 Service primitives for GIVIIVISIVI-SAP 

Session management services for non-anonymous may request GPRS service registration before activating a PDP 
context. 
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Table 9.5.1 : Primitives and parameters at GIVIMSM-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GMMSM-ESTABLISH-REQ 


- 


9.5.1.1 


GMMSM-ESTABLISH-CNF 


- 


9.5.1.2 


GMMSM-ESTABLISH-REJ 


cause 


9.5.1.3 


GMMSM-RELEASE-IND 


- 


9.5.1.4 


GMMSM-UNITDATA-REQ 


SM-PDU 


9.5.1.5 


GMMSM-UNITDATA-IND 


SM-PDU 


9.5.1.6 



9.5.1.1 



GMMSM-ESTABLISH-REQ 



Request from Session Management to send an ATTACH REQUEST message to the network to setup a GMM 
connection. The request is only performed in case the MS is not already attached. The GPRS attach is then indirectly 
caused by a requested non-anonymous PDP context activation. 



9.5.1.2 



GMMSM-ESTABLISH-CNF 



The network has send the ATTACH ACCEPT message to the MS, the indirect attach was successful. Now session 
management can proceed with PDP context activation. 

9.5.1.3 GMMSM-ESTABLISH-REJ 

The network has rejected the attach. The MS has received the ATTACH REJECT message. 

9.5.1.4 GMMSM-RELEASE-IND 

The GPRS mobility management informs the session management that the MS has been GPRS detached, e.g. by timer 
expiry, and therefore the PDP contexts are not valid anymore. 

9.5.1.5 GMMSM-UNITDATA-REQ 

The GMM is requested to forward a SM PDU to LLC in order to send it in unacknowledged more to the peer entity. 

9.5.1.6 GMMSM-UNITDATA-IND 

The GMM forwards a SM PDU, which has been received in unacknowledged mode via LLC from the peer entity. 

9.5.2 Service primitives for GMMAA-SAP 

Session management services for an anonymous PDP require a mobility management entity which does not perform 
Routing Area Updating, but which requests the termination of the anonymous access in case of change of the RA. 
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Table 9.5.2: Primitives and parameters at GIVIMAA-SAP - MS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GMMAA-ESTABLISH-REQ 


- 


9.5.2.1 


GMMAA-RELEASE-IND 


- 


9.5.2.2 


GMMAA-ETSABLISH-REJ 


- 


9.5.2.3 



9.5.2.1 



GMMAA-ESTABLISH-REQ 



Request from Session Management to perform timer supervision (standby timer set to zero) and to disable routing area 
updating for anonymous PDF context(s). 

9.5.2.2 GMMAA-RELEASE-IND 

The GPRS mobility management informs the session management that the anonymous PDP contexts are deactivated. 

9.5.2.3 GMMAA-ESTABLISH-REJ 

The GPRS mobility management informs the session management that the anonymous PDP contexts activation was 
rejected. 

9.5.3 Service primitives for GMMSMS-SAP 

The Short Message entity may request from the GMM entity the GMM IMSI registration state before an MO SMS 
transmission is initiated. 

Table 9.5.3: Primitives and parameters at GIUIMSMS-SAP - IVIS side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GMMSMS-REG-STATE-REQ 


- 


9.5.3.1 


GMMSM- REG-STATE -RSP 


Registration state 


9.5.3.2 



9.5.3.1 GMMSMS-REG-STATE-REQ 

Request for the current IMSI registration state from the Short Message entity. 

9.5.3.2 GMMSM- REG-STATE -RSP 

The current IMSI registration state is sent to the Short Message entity. 



1 Interlayer service interfaces on the Network side 

In addition to the services described in this clause, the RR entity and MM entity also provide services to CM entities 
which don't belong to the functional blocks of CC, SMS, and SS. (For example, the RR entity provides service to Group 
Call Control and Broadcast Call Control entities.) These services are not further described in this clause. 
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1 0.1 Services provided by the Radio Resource IVIanagement 
entity 

The Radio Resource Management (RR) sublayer provides services to the Mobihty Management entity (MM). 
The RR services are used for: 

establishing control channel connections; 

establishing traffic channel connections; 

ciphering mode indication; 

releasing control channel connections; 

control-data transfer. 
The Radio Resource Management services are represented by the RR service primitives. 
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Figure 10.1 : Services provided at RR-SAP - Networic side 



10.1.1 Service state diagram 



The primitives provided by the Radio Resource Management entity and the transition between permitted states are 
shown in figure 10.2. 
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- Data transfer 1 , dedicated channel established. 
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Figure 10.2: Service graph of the Radio Resource IVIanagement entity - Networl< side 

10.1.2 Service primitives 

Table 10.1 : Primitives and Parameters at the RR-SAP - Network side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


RR_EST_REQ 


Parameters for the Initial layer 3 message 


10.1.2.1 


RR_EST_IND 


Initial layer 3 message 


10.1.2.2 


RR_EST_CNF 


- 


10.1.2.3 


RR_REL_REQ 


cause 


10.1.2.4 


RR_REL_IND 


cause 


10.1.2.5 


RR_SYNC_REQ 


cause (resource assign, ciphering) 


10.1.2.6 


RR_SYNC_CNF 


cause (resource assign, ciphering) 


10.1.2.7 


RR_DATA_REQ 


Layer 3 message 


10.1.2.8 


RR_DATA_IND 


Layer 3 message 


10.1.2.9 


RR_UNIT_DATA_REQ 


Layer 3 message 


10.1.2.10 


RR_UNIT_DATA_IND 


Layer 3 message 


10.1.2.11 


RR_ABORT_REQ 


cause 


10.1.2.12 


RR_ABORT_IND 


cause 


10.1.2.13 



10.1.2.1 RR_EST_REQ 

Request used by the Mobility Management entity to request establishment of control channel connections. 



£75/ 



(GSM 04.07 version 6.5.1 Release 1 997) 68 ETSI TS 1 00 939 V6.5.1 (1 999-1 1 ) 

10.1.2.2 RR_ESTJND 

Indication to the Mobility Management entity that the establishment of control channel connections has been done. 

10.1.2.3 RR_EST_CNF 

Confirmation used by RR to confirm the establishment of a requested control channel connection. 

10.1.2.4 RR_REL_REQ 

Request used by the Mobility Management to release a control channel connection. 

10.1.2.5 RR_RELJND 

Indication from RR to MM that the main signalling link has been released. 

10.1.2.6 RR_SYNC_REQ 

Request used by the Mobility Management entity for synchronization with the RR protocol. 

10.1.2.7 RR_SYNC_CNF 

Confirmation used by RR that the requested synchronization is done. 

10.1.2.8 RR_DATA_REQ 

Request used by the Mobility Management entity for acknowledged control-data transmission. 

10.1.2.9 RR_DATAJND 

Indication used by RR to transfer received control-data, which should be acknowledged, to the Mobility Management 
entity. 

10.1.2.10 RR_UNIT_DATA_REQ 

Request used by the Mobility Management entity for unacknowledged control-data transmission. 

10.1.2.11 RR_UNIT_DATAJND 

Indication used by RR to transfer received control-data, which should not be acknowledged, to the Mobility 
Management entity. 

10.1.2.12 RR_ABORT_REQ 

Request of the abandon of the RR connection. 

10.1.2.13 RR_ABORTJND 

Indication that a radio link failure has occurred. 

1 0.2 Services provided by the IVIobility IVIanagement entity 

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, the Supplementary Service 
Support (SS) entity and the Short Message Service Support (SMS) entity. 

The Mobility Management services primitives are recognized by the MMCC, MMSS and MMSMS prefix. 
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Figure 10.3: Services provided at lUIIUICC-SAP, lUIIUISS-SAP, lUIIUISIUIS-SAP - Network side 

1 0.2.1 Service state diagram 

The primitives provided by the Mobihty Management entity towards Call Control, Short Messages Service Support and 
call independent Supplementary Services Support as well as the transition between permitted states are illustrated in 
figure 10.4. 
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Figure 10.4: Service graph of the IVIobility IVIanagement entity, towards Call Control - Network side 
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10.2.2 Service primitives 



Table 10.2: Primitives and Parameters at MMCC-SAP, MMSS-SAP, MMSMS-SAP - Network side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


MMXX_EST_REQ (see note 1) 


Mobile ID 


10.2.2.1 


MMXX_EST_IND (see note 1) 


First CM message 


10.2.2.2 


MMXX_EST_CNF (see note 1) 


- 


10.2.2.3 


MMXX_REL_REQ (see note 1) 


cause 


10.2.2.4 


MMXX_REL_IND (see note 1) 


cause 


10.2.2.5 


MMXX_DATA_REQ (see note 1) 


Layer 3 message 


10.2.2.6 


MMXX_DATA_IND (see note 1) 


Layer 3 message 


10.2.2.7 


MMXX_UNIT_DATA_REQ (see note 1) 


Layer 3 message 


10.2.2.8 


MMXX_UNIT_DATA_IND (see note 1) 


Layer 3 message 


10.2.2.9 


MMCC_SYNC_REQ (see note 2) 


cause (resource assign) 


10.2.2.10 


MMCC_SYNC_CNF (see note 2) 


cause (resource assign) 


10.2.2.11 


NOTE 1 : MMXX is used as substitution for IVIIVICC, IVIIVISS or IVIIVISIVIS. 
NOTE 2: Only at MMCC-SAP. 



10.2.2.1 



MMXX EST REQ 



Request by CC, SS and SMS respectively, for the establishment of a MM connection. 

10.2.2.2 MMXX_ESTJND 

Indication by the MM sublayer that a MM connection is established. 

10.2.2.3 MMXX_EST_CNF 

Confirmation of the MM connection establishment by the MM sublayer. 

10.2.2.4 MMXX_REL_REQ 

Request by CC, SS or SMS respectively, for the release of the MM connection. 

10.2.2.5 MMXX_RELJND 

Indication by the MM sublayer that a MM connection has been released. 

10.2.2.6 MMXX_DATA_REQ 

Request by the CC, SS or SMS entities for acknowledged control-data transmission. 

10.2.2.7 MMXX_DATAJND 

Indication used by MM to transfer the received acknowledged control-data to the CC, SS or SMS entities. 

10.2.2.8 MMXX_UNIT_DATA_REQ 

Request used by the CC, SS or SMS entities for unacknowledged control-data transmission. 

10.2.2.9 MMXX_UNIT_DATAJND 

Indication used by MM to transfer the received unacknowledged control-data to the CC, SS or SMS entities. 
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10.2.2.10 MMCC_SYNC_REQ 

Request used by the CC entity to synchronize with the MM entity (resource assign). 

10.2.2.11 MMCC_SYNC_CNF 

Confirmation used by the MM to inform the CC entity that synchronization is completed (resource assign). 

1 0.3 Services provided by radio resource management entity for 
GPRS services 

This section is informative, the service primitives are defined in GSM 04.60 [10]. They are included here to provide a 
complete overview of the radio interface protocol architecture. 
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1 0.3. 1 Service primitives for GRR-SAP 

Table 10.3.1 Primitives and Parameters at GRR-SAP - network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GRR-DATA-REQ 


LLC PDU, TLLI, CI, DRX, MS CLM, QoS, Priority 


10.3.1.1 


GRR-DATA-IND 


LLC PDU, TLLI, CI 


10.3.1.2 


GRR-UNITDATA-REQ 


LLC PDU, TLLI, CI, DRX, MS CLM, QoS, Priority 


10.3.1.3 


GRR-UNITDATA-IND 


LLC PDU, TLLI, CI 


10.3.1.4 


GRR-STATUS-IND 


TLLI, cause 


10.3.1.5 



10.3.1.1 GRR-DATA-REQ 

Request used by the LLC layer for acknowledged data transmission with a certain priority. 

10.3.1.2 GRR-DATA-IND 

Indication used by RR to transfer received data, which shall be acknowledged, to the LLC layer. 

10.3.1.3 GRR-UNITDATA-REQ 

Request used by the LLC layer for unacknowledged data transmission with a certain priority. 

10.3.1.4 GRR-UNITDATA-IND 

Indication used by RR to transfer received data, which shall not be acknowledged, to the LLC layer 

10.3.1.5 GRR-STATUS-IND 

Indication to upper layers that an error has occurred on the radio interface. The cause for the failure is indicated 

1 0.3.2 Service primitives for GMMRR-SAP 

Table 10.3.2 Primitives and Parameters at GMMRR-SAP - network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GMMRR-PAGE-REQ 


TLLI, IMSI, CI or Cl-list or RAI, priority 


10.3.2.1 



10.3.2.1 GMMRR-PAGE-REQ 

Request by GMM to send a RR -paging message to the mobile station. 
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1 0.4 Services provided by the LLC entity for GPRS services 
1 0.4. 1 Service primitives for LLGIVIIVI-SAP 

Table 10.4.1 Primitives and Parameters at GRR-SAP - network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


LLGMM-ASSIGN-REQ 


newTLLI, oldTLLI, Kc, Algorithm 


10.4.1.1 


LLGMM-TRIGGER-IND 


TLLI 


10.4.1.2 


LLGMM-SUSPEND-REQ 


TLLI, page 


10.4.1.3 


LLGMM-RESUME-REQ 


TLLI 


10.4.1.4 


LLGMM-PAGE-IND 


TLLI 


10.4.1.5 


LLGMM-PAGE-RESP-IND 


TLLI 


10.4.1.6 


LLGMM-WINDOW-REQ 


TLLI 


10.4.1.7 


LLGMM-WINDOW-CNF 


actual LLC's N(R) per SAP 


10.4.1.8 


LL-UNITDATA-REQ 


TLLI, SMM-PDU, protect, cipher 


10.4.1.9 


LL-UNITDATA-IND 


TLLI, SMM-PDU, cipher 


10.4.1.10 


LLGMM-STATUS-IND 


TLLI, cause 


10.4.1.11 



10.4.1.1 



LLGMM-ASSIGN-REQ 



A new TLLI and/or a ciphering key and/or a ciphering algorithm is assigned to the LL sublayer. Also an old TLLI can 
be unassigned. 

10.4.1.2 LLGMM-TRIGGER-IND 

An LLC frame has been received from the mobile station. 

10.4.1.3 LLGMM-SUSPEND-REQ 

All LLC links will cease sending PDUs. The parameter page indicates that data shall be sent if available and therefore 
paging shall be needed. Or the cause indicates that data shall not be sent until a RESUME-REQ is received. 

10.4.1.4 LLGMM-RESUME-REQ 

Normal LLC frame sending and reception is possible again. 

10.4.1.5 LLGMM-WINDQW-REQ 

Request for the actual LLC's N(R)s. 

10.4.1.6 LLGMM-WINDQW-GNF 

The actual LLC's V(R)s for each LLC link in ABM mode are transferred to SMM. 
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10.4.1.7 LLGMM-PAGE-IND 

Requires to send a paging message to the mobile station. 

10.4.1.8 LLGMM-PAGE-RESP-IND 

A paging response has been received from the mobile 

10.4.1.9 LL-UNITDATA-REQ 

Request to send a SMM message in unacknowledged mode to the peer entity. 

10.4.1.10 LL-UNITDATA-IND 

A SMM message in unacknowledged mode has been received from the peer entity. 

10.4.1.11 LLGMM-STATUS-IND 

Indication used by LLC to transfer lower layer failures to the GMM sublayer. 

1 0.4.2 Service primitives for LLSMS-SAP 

Table 10.4.2; Primitives and Parameters at LLSMS-SAP - network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


LL-UNITDATA-REQ 


TLLI, SMS-CP-PDU, protect, cipher 


10.4.2.1 


LL-UNITDATA-IND 


TLLI, SMS-CP-PDU 


10.4.2.2 



10.4.2.1 LL-UNITDATA-REQ 

An LLC UI frame will be sent to the peer entity. 

10.4.2.2 LL-UNITDATA-IND 

An LLC UI frame has been received from the peer entity. 

1 0.5 Services provided by the GMM for GPRS services 
10.5.1 Service primitives for GMMSM-SAP 

Table 10.5.1 : Primitives and Parameters at GMMSM-SAP - network side 



PRIMITIVE 


PARAMETER 

(message, info elements of message, other 
parameters) 


REFERENCE 


GMMSM-RELEASE-IND 


- 


10.5.1.1 


GMMSM-UNITDATA-REQ 


SM-PDU 


10.5.1.2 


GMMSM-UNITDATA-IND 


SM-PDU 


10.5.1.3 
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10.5.1.1 GMMSM-RELEASE-IND 

The GPRS mobility management informs the session management that the MS has been GPRS detached, e.g. by timer 
expiry, and therefore the PDP contexts are not vaHd anymore. 

10.5.1.2 GMMSM-UNITDATA-REQ 

The GMM is requested to forward a SM PDU to LLC in order to send it in unacknowledged more to the peer entity. 

10.5.1.3 GMMSM-UNITDATA-IND 

The GMM forwards a SM PDU, which has been received in unacknowledged mode via LLC from the peer entity. 



1 1 L3 Messages 



This clause specifies the generic methods used in the layer 3 protocol specifications to describe messages. It define in 
particular a generic message structure, that of the "standard L3 messages". Not all messages in layer 3 protocols follow 
this structure, but many do, and this section specifies how to interpret the standard description. 

This clause also addresses basic aspects of the handling of messages received but not compliant with the allowed 
structure. In most cases, only the conditions that lead to the diagnosis of an error are described. The reaction of an entity 
receiving a message leading to such a diagnosis is in general specified for each protocol in the relevant protocol 
specification. 

11.1 General 
11.1.1 Messages 

For all concerned protocols, concrete messages are bit strings of variable length, formally a succession of a finite, 
possibly null, number of bits (i.e., elements of the set { "0", " 1 " }), with a beginning and an end. 

The services provided by lower layers includes the transmission of such bit strings. 

Considered as messages, these bit strings follow some structure (the syntax), enabling to organise bits in information 
pieces of a different meaning level. 

The term message is used as well for a concrete message (i.e., a bit-string, as defined by the giving of all its bits, in 
practice appearing at one point of time in a concrete dialog), as for a class of concrete messages sharing a common 
structure. A concrete message is an instance of the corresponding class of messages. Message classes can be described 
as sets of potential bit strings, and of a common structure, enabling in particular to identify parts meaningful for the co- 
operation functions the protocol supports. 

In general, in the rest of the clause as in the protocol specifications, the term message will be used to refer to the class. It 
may be used, when the context prevents ambiguity, to refer to a message instance (e.g., a received is usually a message 
instance). In the rest of this clause, the term message instance will be used when needed to refer unambiguously to 
specific concrete message, i.e., to a specific bit string. 

A message (message class) can be described directly as a set of bit strings, using the formal notation described in 
annex B. 

A message can also be described as a standard L3 message, in which case the interpretation of the message description 
in term of a set of bit strings is specified in the next sub-clauses. 
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In all cases, structuring messages is based on the underlying bit string. Thus, the following terms are used : 

a part of a message instance is a sub-string of the corresponding string ; a part of a message (as a class) is 
described by a definition applicable to all instances; a part of a message then is both a structural attribute of the 
message as a class, and a set of sub-strings, composed of the sub-strings obtained by applying the definition to 
each possible instance ; for instance, « the first octet » of a message instance is defined from the moment its 
length is greater than 8, and is the sub-string composed of the first 8 bits of the message instance; the « first 
octet » of a message as a class is the structural definition given above, and the set of all 8-bit octet strings that can 
be obtained as the first octet of one instance of the class. 

'part A follows part B' means that in the message the sub-string corresponding to part B is concatenated with the 
sub-string of part B ; 

the length of a message instance, or of part of message instance, is the number of bits of the corresponding sub 
string ; rigorously speaking, a message as a class (or a part seen as a class) has a length only if all the 
corresponding instances have the same length ; by extension, sentences such as « a message as a length in the 
range so and so » means that the length of an instances of the class always fall in the range. 

11.1.2 Octets 

In many places, a message is described as a succession of octets. An octet is generally a succession of 8 bits. Unless 
otherwise indicated, the term octet is used more restrictively to refer to a part of message, defined when considering a 
message as a succession of octets, e.g., the first 8 bits of a message, or the 17* to the 23"^, form an octet, but not the 
second bit to the 9*. 

Unless specified otherwise, the numbering conventions are the following: 

Octets in a message or in a part are numbered from 1 onward, starting at the beginning of the bit string. This numbering 
can be strictly applied only for message instances, and for the first part of a message structurally identical for all 
instances. 

Bits in octets are numbered from 8 down to 1, starting at the beginning of the octet. 

When represented as tables showing the different bit positions, octets are presented in the natural occidental order, i.e., 
from the top of a page downward. Bits in octets are presented with the first bit on the left of the page. 

11.1.3 Integer 

In many places, message parts are described as encoding integers. Two generic encoding are defined in this subclause. 

11.1.3.1 Binary 

A message part is said to encode in binary an integer to indicate that concrete strings are mapped, for some usage, on the 
set of non signed integers with the following rule: 

Let k denote the length of the bit string, and let b(i) denote an integer of value if the i* bit in the string is "0", and 1 
otherwise. The encoded integer n respects the equation: 

i=\tok 

11.1.3.2 2-complement binary 

A message part is said to encode in 2-complement binary an integer to indicate that concrete strings are mapped, for 
some usage, on the set of signed integers with the following rule: 
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Let k denote the length of the bit string, and let b(i) denote an integer of value if the i bit in the string is "0", and 1 
otherwise. The encoded integer n respects the equation: 



ifZ7(l) = then n= Y,b(i)^'~'~' 

i-ltok 

else n= ^^7(02'"'"' - 2* 



i = ]lok 



11.1.4 Spare parts 

In some cases the specification is that which message instances can be accepted by a receiver comprise more that the 
legal message instances that can be sent. One example of this is the notion of spare bit. A spare bit has to send as the 
value indicated in the specification (typically 0), but can be accepted as a or a 1 by the receiver without error 
diagnosis. A spare field is a field composed entirely of spare bits. 

1 1 .2 Standard L3 messages 

1 1 .2.1 Components of a standard L3 message 

A standard L3 message consists of an imperative part, itself composed of a header and the rest of imperative part, 
followed by a non-imperative part. Both the non-header part of the imperative part and the non-imperative part are 
composed of successive parts referred as standard information elements. 

11 .2.1 .1 Format of standard information elements 

A standard IE may have the following parts, in that order: 

an information element identifier (lEI); 

a length indicator (LI); 

a value part. 
A standard IE has one of the formats shown in table 11.1: 

Table 11.1 : Formats of information elements 



Format 


Meaning 


lEI present 


LI present 


Value part present 


T 


Type only 


yes 


no 


no 


V 


Value only 


no 


no 


yes 


TV 


Type and Value 


yes 


no 


yes 


LV 


Length and Value 


no 


yes 


yes 


TLV 


Type, Length and Value 


yes 


yes 


yes 



Some lEs may appear in the structure, but not in all instances of messages. An IE is then said to be present or not present 
in the message instance. If an IE is not present in a message instance, none of the three parts is present. Otherwise, parts 
must be present according to the IE format. 

In the message structure, an IE that is allowed not to be present in all message instances is said not to be mandatory. 
Other lEs are said to be mandatory. 



11.2.1.1.1 



Information element type and value part 



Every standard IE has an information element type which determines the values possible for the value part of the IE, and 
the basic meaning of the information. The information element type describes only the value part. Standard lEs of the 
same information element type may appear with different formats. The format used for a given standard IE in a given 
message is specified within the description of the message. 
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The value part of a standard IE either consists of a half octet or one or more octets; the value part of a standard IE with 
format LV or TLV consists of an integral number of octets, between and 255 inclusive ; it then may be empty, i.e., 
consist of zero octets; if it consists of a half octet and has format TV, its lEI consists of a half octet, too. The value part 
of a standard IE may be further structured into parts, called fields. 



11.2.1.1.2 



Length indicator 



When present, the LI of a standard IE consists of one octet. It contains the binary encoding of the number of octets of 
the IE value part. The length indicator of a standard IE with empty value part indicates octets. Standard IE of an 
information element type such that the possible values may have different values must be formatted with a length field, 
i.e., LV or TLV. 



11.2.1.1.3 



Information element identifier 



When present, the lEI of a standard IE consists of a half octet or one octet. A standard IE with lEI consisting of a half 
octet has format TV, and its value part consists of a half octet. The value of the lEI depends on the standard IE, not on 
its information element type. The lEI, if any, of a given standard IE in a given message is specified within the 
description of the message. In some protocol specifications, default lEI values can be indicated. They are to be used if 
not indicated in the message specification. Non mandatory standard IE in a given message, i.e., IE which may be not be 
present (formally, for which the null string is acceptable in the message), must be formatted with an lEI, i.e., with format 
T, TV or TLV. 

1 1 .2.1 .1 .4 Categories of lEs; order of occurrence of lEI, LI, and value part 

Totally four categories of standard information elements are defined: 

information elements of format V or TV with value part consisting of 1/2 octet (type 1); 

information elements of format T with value part consisting of octets (type 2); 

information elements of format V or TV with value part that has fixed length of at least one octet (type 3); 

information elements of format TLV or LV with value part consisting of zero, one or more octets (type 4); 

Type 1 standard information elements of format V provide the value in bit positions 8, 7, 6, 5 of an octet (see 
figure 11.1) or bits 4, 3, 2, 1 of an octet (see figure 11. 2). 



8 



1 



value part 


- 



Figure 11.1: Type 1 IE of format V 

8 7 6 5 4 3 2 1 



value part 



Figure 11.2: Type 1 IE of format V 

Type 1 standard information elements of format TV have an lEI of a half octet length; they provide the lEI in bit 
positions 8, 7, 6, 5 of an octet and the value part in bit positions 4, 3, 2, 1 of the same octet, see figure 11.3. 



8 



1 



lEI 


value part 



Figure 11.3: Type 1 IE of format TV 

A type 2 standard IE has format T; its lEI consists of one octet, its value part is empty, see figure 1 1 .4. 
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lEI 



Figure 11.4: Type 2 IE 

A type 3 standard information element has format V or TV; if it has format TV, its lEI consists of one octet and 
proceeds the value part in the IE. The value part consists of at least one octet. See figure 1 1.5 and figure 1 1.6. 



octet n 

octet n + k 
Figure 1 1 .5: Type 3 IE of format V (k = 0, 1 , 2, ...) 
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part 
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Figure 1 1 .6: Type 3 IE of format TV (k = 1 , 2, ...) 

A type 4 standard information element has format LV or TLV. Its LI precedes the value part, which consists of zero, 
one, or more octets; if present, its lEI has one octet length and precedes the LI. See figure 11. 7 and figure 1 1.8. 
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Figure 1 1 .7: Type 4 IE of format LV (k = 0, 1 , 2, ...) 

8 7 6 5 4 3 2 1 




octet n + k 



Figure 11.8: Type 4 IE of format TLV (k = 1, 2, ...) 
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1 1 .2.2 Description metlnods for IE structure 

Standard lEs can be further structured in parts called fields. Two description methods are recommended and described 
hereafter. 

11.2.2.1 Tables 

According to this description method, the IE is presented in its maximum format, i.e., T, TV or TLV, in a picture 
representing the bits in a table, each line representing an octet. Bits appear in the occidental order, i.e., from left of the 
page to right of the page, and from top of the page to bottom of the page. 

Boxes so delimited contains typically the field name, possibly an indication of which bits in the field are in the box, and 
possibly a value (e.g., for spare bits). 

A specific method can be used in the IE description to describe a branching structure, i.e., a structure variable according 
to the value of particular fields in the IE. This design is unusual outside type 4 lEs, and as, a design rule, should be used 
only in type 4 lEs. 

a) The octet number of an octet within the IE is defined typically in the table. It consists of a positive integer, 
possibly of an additional letter, and possibly of an additional asterisk, see clause f). The positive integer identifies 
one octet or a group of octets. 

b) Each octet group is a self contained entity. The internal structure of an octet group may be defined in alternative 

ways. 

c) An octet group is formed by using some extension mechanism. The preferred extension mechanism is to extend 
an octet (N) through the next octet(s) (Na, Nb, etc.) by using bit 8 in each octet as an extension bit. 

The bit value "0" indicates that the octet group continues through to the next octet. The bit value "1" indicates 
that this octet is the last octet of the group. If one octet (Nb) is present, the preceding octets (N and Na) shall also 
be present. 

In the format descriptions appearing in section 10.5.1 to 10.5.4, bit 8 is marked "0/1 ext" if another octet follows. 
Bit 8 is marked " 1 ext" if this is the last octet in the extension domain. 

Additional octets may be defined in later versions of the protocols ("1 ext" changed to "0/1 ext") and equipments 
shall be prepared to receive such additional octets; the contents of these octets shall be ignored. However the 
length indicated in sections 9 and 10 only takes into account this version of the protocols. 

d) In addition to the extension mechanism defined above, an octet (N) may be extended through the next octet(s) 
(N+1, N+2 etc.) by indications in bits 7-1 (of octet N). 

e) The mechanisms in c) and d) may be combined. 

f) Optional octets are marked with asterisks (*). As a design rule, the presence of absence of an optional octet 
should be determinable from information in the IE and preceding the optional octet. Care should be taken not to 
introduce ambiguities with optional octets. 

11.2.2.1.1 Compact notation 

The compact notation described in Annex B can be used to describe the value part of a standard IE. This method is 
recommended for complex structures, or for a branching structure not respecting octet boundaries. 

1 1 .2.3 Imperative part of a standard L3 message 

The imperative part of a standard L3 message is composed a header possibly followed by mandatory standard lEs 
having the format V or LV. 
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11.2.3.1 Header 

The header of a standard L3 message is composed of two octets, and structured in three main parts, the protocol 
discriminator (1/2 octet), a message type octet, and a half octet used in some cases as a Transaction Identifier and called 
skip indicator otherwise. 

11.2.3.1.1 Protocol discriminator 

Bits 1 to 4 of the first octet of a standard L3 message contain the protocol discriminator (PD) information element. The 
PD identifies the L3 protocol to which the standard layer 3 message belongs. The correspondence between L3 protocols 
and PDs is one-to-one. 

For future evolution an extension mechanism is foreseen which allows the use of protocol discriminators with one octet 
length, where bits 4 to one are coded as 1 1 1 0. Messages of such protocols may not be standard L3 messages. In 
particular, the rest of the header may not respect the structure described in this sub-clause. 

The PD can take the following values: 

Table 11.2: Protocol discriminator values 



bits 4 3 2 1 




0000 


group call control 


0001 


broadcast call control 


00 10 


PDSS1 


00 11 


call control; call related SS messages 


0100 


PDSS2 


0101 


mobility management messages 


0110 


radio resources management messages 


1000 


GPRS mobility management messages 


100 1 


SMS messages 


10 10 


GPRS session management messages 


10 11 


non call related SS messages 


1110 


reserved for extension of the PD to one octet length 


1111 


reserved for tests procedures described in GSIV1 11.10 



If the network receives, on a SAP where it expects standard L3 messages, a message with a protocol discriminator 
different from those specified in table 11. 2, the network may ignore the message or initiate the channel release 
procedure defined in GSM 04.08. 

If the Mobile Station receives, on a SAP where it expects standard L3 messages, a standard L3 message with a protocol 
discriminator different from those specified in table 1 1 .2, or for a protocol that it does not support, the Mobile Station 
shall ignore the message. 

11.2.3.1.2 Skip indicator 

Bits 5 to 8 of octet 1 of a standard L3 message may be used differently, depending on the protocol and the SAP. The use 
of this half-octet is consistent for a given PD and SAP. One possibility is that this half-octet contains the skip indicator. 
Unless otherwise specified in the protocol, the skip indicator IE is a spare field. 

1 1 .2.3.1 .3 Transaction identifier 

A L3 protocol may define that bits 5 to 8 of octet 1 of a standard L3 message of the protocol contains the transaction 
identifier (TI). The TI allows to distinguish up to 16 different bi-directional messages flows for a given PD and a given 
SAP. Such a message flow is called a transaction. 

The TI IE is coded as shown in figure 11.9 and table 11.3. It is composed of the TI value and the TI flag. 

The TI value and the TI flag occupy bits 5-7 and bit 8 of the first octet respectively. 
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Transactions are dynamically created, and their TI value is assigned at creation time. TI values are assigned by the side 
of the interface initiating a transaction. At the beginning of a transaction a free TI value (i.e., a value not yet used for the 
given PD, the given SAP, and with the given initiator) is chosen and assigned to this transaction. It then remains fixed 
for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a 
later transaction. 

Two identical TI values may be used when each value pertains to a transaction initiated by the different sides of the 
interface. In this case the TI flag shall avoid ambiguity. The transaction identifier flag can take the values "0" or "1". 
The TI flag is used to identify which side of the interface initiated the transaction. A message has a TI flag set to "0" 
when it belongs to transaction initiated by its sender, and to " 1 " otherwise. 

Hence the TI flag identifies who allocated the TI value for this transaction and the only purpose of the TI flag is to 
resolve simultaneous attempts to allocate the same TI value. 

The TI may in future evolutions of the L3 protocols be extended by using a combination of bits in the TI value field that 
is specified as "reserved for future extension" in table 11.3. In the present version, messages received on a SAP where 
standard L3 messages are expected and with a TI of TI value 111 may be ignored. 



8 



TI 

flag 



TI 
value 



octet 1 



Figure 11.9: Transaction identifier 



Table 11.3. Transaction identifier 



TIflag (octet 1) 




Bit 




8 







The message is sent from the side that originates the TI 


1 


The message is sent to the side that originates the TI 


TI value (octet 1) 




Bits 




765 




000 


TI value 


00 1 


- - 1 


01 


- - 2 


01 1 


- - 3 


1 00 


- - 4 


1 1 


- - 5 


1 1 


- - 6 


1 1 1 


Reserved for future extension. 



1 1 .2.3.2 Message type octet 

The message type octet is the second in a standard L3 message. 

When a standard L3 message is expected, and a message is received that is less than 16 bit long, that message shall be 
ignored. 

The message type IE is coded as shown in figure 1 1.10. 

Bit 8 is encoded as "0"; value "1" is reserved for possible future use as an extension bit. A protocol entity expecting a 
standard L3 message, and receiving a message containing bit 8 of octet 2 encoded as " 1 " shall diagnose a " message not 
defined for the PD" error and treat the message accordingly. 
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In messages sent using the transmission functionality provided by the RR layer to upper layers, and sent from the mobile 
station to the network , bit 7 of octet 2 is used by the RR protocol. 

In all other standard layer 3 messages bit 7 is set to A protocol entity expecting a standard L3 message, and not using 
the transmission functionality provided by the RR layer, and receiving a message containing bit 7 of octet 2 encoded as 
1 shall diagnose a "message not defined for the PD" error and treat the message accordingly. 

8 7 6 5 4 3 2 1 

octet 1 






N(SD) 
orO 


Message type 



Figure 11.10: Message type IE 

Bit 1 to 6 of octet 2 of standard L3 messages contain the message type. 

The message type determines the function of a message within a protocol in a given direction and for a given lower layer 
SAP. The meaning of the message type is therefore dependent on the protocol (the same value may have different 
meanings in different protocols), the direction (the same value may have different meanings in the same protocol, when 
sent from the Mobile Station to the network and when sent from the network to the Mobile Station) and the lower layer 
SAP (the same value may have different meanings, e.g., whether the message was sent on the SACCH or on the main 
DCCH). 

Each protocol defines a list of allowed message types for each relevant SAP. A message received analysed as a standard 
L3 message, and with a message type not in the corresponding list leads to the diagnosis "message not defined for the 
PD". Some message types may correspond to a function not implemented by the receiver. They are then said to be non 
implemented by the receiver. 

The reaction of a protocol entity expecting a standard L3 message and receiving a message with message type not 
defined for the PD or not implemented by the receiver and the reception conditions is defined in the relevant protocol 
specification. As a general rule, a protocol specification should not force the receiver to analyse the message further. 

1 1 .2.3.3 Standard information elements of the imperative part 

The message type octet of a standard L3 message may be followed by mandatory standard lEs having the format V or 
LV as specified in the message description in the relevant protocol specification. 

As a design rule, octet boundaries must be respected. This implies that half-octet standard IBs (i.e., V formatted type 1 
standard IBs) must appear by pair. 

If message is received as a standard L3 message, and that is too short to contain the complete imperative part as 
specified in the relevant protocol specification, an imperative message part error is diagnosed. (The same error may be 
diagnosed at detection of certain contents of the imperative part of a message; this is defined in the relevant protocol 
specification.) The treatment of an imperative message part error is defined in the relevant protocol specification. 

1 1 .2.4 Non-Imperative part of a standard L3 message 

The imperative part of a standard L3 message is followed by the (possibly empty) non-imperative part. The relevant 
protocol specification defines where the imperative part of a standard L3 message ends. The non-imperative part of a 
standard L3 message is composed of (zero, one, or several) standard IBs having the format T, TV, or TLV. The receiver 
of a standard L3 message shall analyse the non imperative part as a succession of standard IBs each containing an IBI, 
and shall be prepared for the non-imperative part of the message to contain standard IBs that are not specified in the 
relevant protocol specification. 

An IBI may be known in a message or unknown in a message. Bach protocol specification lists, for each message (i.e., 
according to the message type, the direction and the lower layer SAP), the known standard IBs in the non-imperative 
part. 

An IBI that is known in a message designates the IB type of the IB the first part of which the IBI is, as well as the use of 
the information. Which IB type it designates is specified in the relevant protocol specification. Within a message, 
different IBIs may designate the same IB type if that is defined in the relevant protocol specification. 
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Whether the second part of an IE with lEI known in a message is the length or not (in other words, whether the lEI is the 
first part of an IE formatted as TLV or not) is specified in the relevant protocol specification. 

Unless otherwise specified in the protocol specification, the receiver shall assume that IE with unknown lEI are TV 
formatted type 1, T formatted type 2 or TLV formatted type 4 standard lEs. The lEI of unknown lEs together with, when 
applicable, the length indicator, enable the receiver to determine the total length of the IE, and then to skip unknown lEs. 
The receiver shall assume the following rule for lEs with unknown lEI : 

Bit 8 of the lEI octet is set to " 1 " indicates a TV formatted type 1 standard IE or a T formatted type 2 lEs, and to 
"0" indicates a TLV formatted type 4 IE. Hence, a 1 valued bit 8 indicates that the whole IE is one octet long, 
and a valued bit 8 indicates that the following octet is a length octet. 

As a design rule, it is recommended that lEIs of any TV formatted type 1, T formatted type 2 or TLV formatted type 4 
IE follow the rule, even if assumed to be known by all potential receivers. 

A message may contain two or more lEs with equal lEI. Two lEs with the same lEI in a same message must have the 
same format, and, when of type 3, the same length. More generally, care should be taken not to introduce ambiguities by 
using an lEI for two purposes. Ambiguities appear in particular when two lEs potentially immediately successive have 
the same lEI but different meanings and when both are non-mandatory. As a recommended design rule, messages should 
contain a single IE of a given lEI. 

Each protocol specification may put specific rules for the order of lEs in the non-imperative part. An IE known in the 
message, but at a position non compliant with these rules is said to be out of sequence. An out of sequence IE is decoded 
according to the format, and, when of type 3 the length, as defined in the message for its lEI. 

1 1 .2.5 Presence requirements of information elements 

The relevant protocol specification may define three different presence requirements (M, C, or O) for a standard IE 
within a given standard L3 message: 

M ("Mandatory") means that the IE shall be included by the sending side, and that the receiver diagnoses a 
"missing mandatory IE" error when detecting that the IE is not present. An IE belonging to the imperative part of 
a message has presence requirement M. An IE belonging to the non-imperative part of a message may have 
presence requirement M; 

C ("Conditional") means: 

* that inclusion of the IE by the sender depends on conditions specified in the relevant protocol specification; 

* that there are conditions for the receiver to expect that the IE is present and/or conditions for the receiver to 
expect that the IE is not present in a received message of a given PD, SAP and message type; these conditions 
depend only on the content of the message itself, and not for instance on the state in which the message was 
received, or on the receiver characteristics; they are known as static conditions; 

that the receiver detecting that the IE is not present when sufficient static conditions are fulfilled for its 
presence, shall diagnose a "missing conditional IE" error; 

that the receiver detecting that the IE is present when sufficient static conditions are fulfilled for its non- 
presence, shall diagnose an "unexpected conditional IE" error. 

Only lEs belonging to the non-imperative part of a message may have presence requirement C; 

O ("Optional") means that the receiver shall never diagnose a "missing mandatory IE" error, a "missing 
conditional IE" error, or an "unexpected conditional IE" error because it detects that the IE is present or that the 
IE is not present. (There may however be conditions depending on the states, resources, etc. of the receiver to 
diagnose other errors.) Only lEs belonging to the non-imperative part of a message may have presence 
requirement O. 

Unless otherwise specified the presence of a IE of unknown lEI or of an out of sequence IE shall not lead by itself to an 
error. An alternative specification is the 'comprehension required' scheme. An IE is encoded as 'comprehension required' 
if bits 5, 6, 7 and 8 of its lEI are set to zero.. The comprehension required scheme is to be applied if explicitly indicated 
in the protocol specification. The reaction on the reception of an unknown or out of sequence IE coded as 
'comprehension required' is specified in the relevant protocol specification. 
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1 1 .2.6 Description of standard L3 messages 

This sub-clause describes a generic description method for standard L3 messages, the tabular description. Protocol 
specification may follow other methods. 

A standard L3 message is described by a table listing the header elements and the standard lEs in the message. For each 
element is given 

if applicable the lEI, in hexadecimal representation (one digit followed by and hyphen for TV formatted type 1, 
and two digits for the other cases); 

The name of the IE (this is used in particular for the description of conditional presence rules); 

The type of the information element, with a reference of where the internal structure of the value part is specified; 

- The format of the standard IE (T, V, TV, LV or TLV); and 

The length, or the range of lengths, of the whole standard IE, including when applicable the T and L parts. 

The list of elements is given in the table in the order they appear in the resulting bit string, with the exception of half- 
octet elements in the imperative part : half octets in a pair are inverted. This applies in particular for the two first header 
elements : the protocol discriminator appears first in a table describing a standard L3 message. 

1 1 .3 Non standard L3 messages 

In some protocols, the structure of part or all of the messages might not always follow the standard L3 message 
structure. As a design rule, this should be consistent for a given protocol, direction and lower layer SAP. 

A possibility is to describe the message with the compact notation described in Annex B. 

A few consistent structures are found in the present protocol specifications, and are described hereafter. 

Other structures can be described directly in the protocol specifications. 

1 1 .3.1 Case A : BCCH and AGCH/PCH messages 

In these cases, the SAP capability is for fixed length messages. The messages are structured as standard L3 messages 
plus one octet in front, the L2 pseudo length octet, and a rest octet part at the end. 

1 1 .3.1 .1 L2 Pseudo Length octet 

This octet, the L2 pseudo length indicator octet, indicates the length in octets of the subsequent octet string that can be 
analysed as a standard L3 message . 

The octet is structured as follows : 

Bits 3 to 8 encodes in binary the L2 pseudo length, i.e., the length of the part to be analysed as a standard L3 
message ; 

Bit 2 is set to "0" ; 

Bit 1 is set to "1". 

A receiver expecting a message so structured and receiving a message with bit 1 of octet 1 (i.e., the 8* bit of the 
message) set to "1" and bit 2 of octet 1 (i.e., the 7* bit of the message) different from "0", shall abandon the analysis of 
the message. 

A receiver expecting a message so structured and receiving a message with an L2 pseudo length indicator encoding or 
1 shall skip the indicated number of octets and not try to analyse the standard L3 message part. 

A receiver expecting a message so structured and receiving a L2 pseudo length indicator bigger than what is compatible 
with the SAP capability shall abandon the analysis of the message. 
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11.3.1.2 Rest Octets 

The part after the part structured as a standard L3 message, and up to the end of the message as constrained by lower 
layers, is presented as a non standard IE of variable length (sometime indicated as of type 5), the 'rest octets' IE. 

The rest octets element may be described by table description, or, preferably, using the compact notation described in 
Annex B of the present document. 

1 1 .3.1 .3 Description of a modified standard L3 message 

The description can be provided in the same way as a standard L3 message, with in the case of a tabular description one 
non standard IE at the beginning (of type L2 pseudo length), and one non standard IE at the end. 

1 1 .3.2 Case B : SACCH messages sent in unacknowledged mode 

The messages are structured either as standard L3 messages, or in the so-called short header format. The value of the 8* 
bit (bit 1 of octet 1) of the link layer PDU distinguishes the two cases. In the case of the short header, the L3 message is 
the same bit string as the link layer PDU, and has a fixed length. The following description includes the 2-bit link layer 
header. 

11.3.2.1 The first octet 

Bits 1 and 2 are the link layer header. Bit 2 of octet 1 is set to "0", and bit 1 is reserved for the link layer. 

A protocol discriminator is the first part of the message (starting bit 8 of octet 1). The protocol discriminator field may 
have different lengths. The following protocol discriminator is defined : 

RR 

All additional PD defined for this structure shall start by 1 . The reception of a message with bit 8 of octet 1 set to 1 
when expecting a message structured as defined by this clause shall be diagnosed as an unknown PD, and the message 
ignored. 

As a design rule, a message type field should follow the PD, and of a length such that the PD and the message type fit in 
the 6 first bits of the message. 

1 1 .3.2.2 The rest of the message 

The rest of the structure is not more constrained. 

The preferred description method is the one described in Annex B. 

1 1 .3.3 Design guidelines for non standard parts 

The guidelines in this sub-clause apply to non standard parts, such as rest octets, short header broadcast message or fully 
non standard L3 messages. 

11.3.3.1 General 

The structure should be as far as possible be such that the analysis can be conducted from beginning to end. In other 
terms, the conditions determining the syntactic analysis of a part (e.g., tags, lengths) should appear before that part. 

The part should be structured as a succession of information elements, each carrying an elementary semantic 
information. An information element should be composed of (possibly) a tag, than (possibly) a length indicator, then a 
value part. 

Tags can be of fixed or variable length, their extent being analysable from beginning to end. A typical tagging is the one 
bit tagging, which should preferably used as follows : value "0" indicates that the IE is no more than the tag bit, and "1" 
indicates that the IE continues at least with the next bit. 
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Variable length tagging should be used to distinguish between several possible formats of the element. Tag lengths are 
then chosen according to packing efficiency criteria. 

The T field of standard lEs can be presented as a variable tagging with only two lengths : 4 and 8 bits. 

The length indicator can be of fixed or variable length, their extent being analysable from beginning to end. It should 
preferably be presented as encoding the length in bits of the value part. 

The L field of standard lEs can be presented as a fixed length (one octet) length indicator which can encode only lengths 
multiple of 8 bits. 

The value part can be described as further structured, in a similar way. This can be used to help the reading, and to cover 
some presence dependence. 

1 1 .4 Handling of superfluous information 

All equipment should be able to ignore any extra information present in an L3 message, which is not required for the 
proper operation of that equipment. For example, a mobile station may ignore the calling party BCD number if that 
number is of no interest to the Mobile Station when a SETUP message is received. 

11 .4.1 Information elements that are unnecessary in a message 

The relevant protocol specification may define certain lEs to be under some conditions unnecessary in a L3 message. A 
protocol entity detecting an unnecessary IE in a received L3 message shall ignore the contents of that IE for treating the 
message; it is not obliged to check whether the contents of the IE are syntactically correct. 

1 1 .4.2 Other syntactic errors 

This section applies to the analysis of the value part of an information element. It defines the following terminology: 

An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved", 
or if its value part violates syntactic rules given in the specification of the value part. However it is not a 
syntactical error that a type 4 standard IE specifies in its length indicator a greater length than possible according 
to the value part specification : extra bits are ignored. 

A message is defined to have semantically incorrect contents if it contains information which, possibly dependant 
on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part. 



£75/ 



(GSM 04.07 version 6.5.1 Release 1997) 



88 



ETSI TS 100 939 V6.5.1 (1999-11) 



Annex A (informative): 
MN-Services arrow diagram 
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Figure A.1 : Mobile originated Call Setup. Successful case 
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Figure A.2: Mobile terminated Call Setup. Successful case 
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Figure A.3: Mobile originated, Call Release and Channel Release. Successful case 
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Figure A.4: Location updating. Successful case 
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Figure A.6: Establishment of parallel transactions (General view) 



£75/ 



(GSM 04.07 version 6.5.1 Release 1997) 



94 



ETSI TS 100 939 V6.5.1 (1999-11) 



5 






■p "8 



^ 



DC 



A 



cc 
cc 



^ 



5) 



^ 



cii 



-r 



A 



A 



A 



^ 



N^ 



_^ 



^ 



Figure A.7: Release of parallel transactions (General view) 
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Annex B (informative): 
Description of CSN.1 



The goal of the notation described hereafter is to describe the structure of the syntactically correct messages for a given 
signalling protocol, or of part of such messages. The notation addresses the cases where the concrete messages are 
binary strings. The notation allows to describe sets of strings : the structure of a message defined a protocol defines a set 
of allowable bit strings. It also allows to put labels on parts of strings that follow a given structure. 

One aspect of the specification of message set is to define the set of strings that are acceptable as when received. All the 
strings that cannot be recognised as syntactically correct messages are to be rejected for syntactical reasons. In many 
cases, only a subset of this set are allowed to be sent. The notation allows also to distinguish the set of the strings that 
can be sent and the set of strings that are recognised as syntactically correct. 

Another aspect of the specification of messages is the splitting of an acceptable string in a number of sub-strings that 
will be use to derive the exact significance of the message. The notation provides this function by labelling sub-strings. 
These labels can then in turn be used in textual or formal semantic descriptions which are not covered in the present 
document. 

The notation described here could be enhanced in the future, with the addition of new rules. 



B.1 The Basic Rules 



The following rules (B 1 to B6) form the core part of the notation, more or less directly inherited from BNF. Rules B7 to 
B8 add what is needed in addition to encode the rest octet parts of fixed length messages as defined in GSM 04.08. 

Rule Al is not needed to describe sets of strings at this stage. It is the one allowing to label parts of messages. 

B.1.1 Core Rules 
B.1.1.1 RuleBI: Bits 

A "bit string" is an ordered sequence of symbols, each belonging to a two-value set. 

The character "0" and " 1 " are used to indicate one bit, respectively of one or the other value. 

Formally, the notations « » and « 1 » denote each a set composed of a single bit string of a single bit, of different 
values. 

In addition the word "bit" denotes the set of the two 1-bit long strings, namely and 1. 

B.1.1. 2 Rule B2 : Null String 

Where needed, the word "null" call be used to indicate the null string, i.e., the string of no symbols. 
Formally, the notation « null » denote the set composed of a single bit string, the empty string. 

B. 1 . 1 .3 Rule B3 : Concatenation 

A succession of two string descriptions describe the concatenation of the strings. 

More formally : a succession of two string descriptions describes the strings obtained by concatenation of one string 
taken in the subset described by the first string description and then one string taken in the subset described by the 
second string description. The rule extends to any number of string descriptions. 

For instance 

00 
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This denotes the set composed of the single bit string of length 2 composed of two zeros. 

B.1.1.4 Rule B4 : Choice 

A list of choices is noted using as separator the character "I". An alternative notation uses instead the word "or" (this is 
not used in the present document). 

NOTE: An idea is to allow not to used strange characters, by giving in each case a verbose equivalent. This is not 
done systematically yet in the present document. 

Formally : the notation A I B, where A and B are string set descriptions, describes the set of the strings which are in the 
set described by A or in the set described by B, that is the union of sets described by A and B. 

The concatenation has a higher precedence than the choice. 

Examples: 





00 101 


This indicates that bit strings 00 and 01 are part of the set (10 and 1 1 are not). 




Oil 



denotes the same set as "bit". 

The characters " { " and " } " are used for delimiting a string set description from what follows and/or precedes. 



0{Ollj 



This indicates the same set of bit strings as in the previous case. 
Precedence example : 



10111 
1011 



Because of the priority rule, the two descriptions are not equivalent, the second noting the set (10, 1). 

It is allowed that the different sets in a choice have non null intersections. To allow message decoding, a rule must then 
be given to choose the branch. The rule is that any matching set can be chosen (the concatenation is a true set union). 

In practice, it is preferable to have non intersecting choice sets. Moreover, the ability to select the branch to take rapidly 
is important for obtaining simple message decoders. Except for strong reasons, a design should only include choice 
construction that can be rewritten using only constructions matching the pattern {al si \a2 s2} where al and a2 are non- 
intersecting sets of strings of the same non-null length. A tolerable derogation is to use intersecting an. 

Examples: 

{ 100 XX I 001 zz} is acceptable. 

{00 XX I 010 yy I 01 1 zz} is acceptable, since it can be rewritten {00 xx 101 {0 yy I 1 zz} } }. 

{ {00101110} XX I {0011 1 } yy} is not recommended (the start 00 is ambiguous). 

In practice this covers fixed length tagging (like tagging by an lEI, or 1-bit tagging in rest octets), and also non- 
intersecting variable length tagging as used for instance in the frequency list IE (tag list such as 0, 100, 101, 110, 11 100, 
1 1 101, 11110, mil, where no tag is the start of another one). 



B.1.1.5 Rule B5 : Naming 



The characters "<" and ">" are used to delimit a reference to the description of a string set. This can be used inside a 
string set description, to refer to a string set described elsewhere. 

For compilability, the name must be used somewhere else to define the corresponding string set. For a simple 
description, the description of the reference could be done by normal text. 
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The name, that is the part sequence of characters between "<" and ">" must not be empty, and is constituted freely of 
characters, with the exception of "<" and ">". Case is not significant, nor are heading or taihng spaces. Any succession 
of space characters is treated as a single character. To avoid difficulties with more advanced rules, the use of the 
characters ":", "=", "(" and ")" should be avoided. More generally, it is not recommended to use many other characters, 
such as "<" for instance. The space character can (and should!) be used, to allow a good legibility for human beings. 

Example : 



<bit pair> 



B.1.1.6 Rule B6 : Definition 

A reference followed by the character sequence "::=" followed by a string set description is used to associate the 
description with the reference, terminated when needed to separate it from a following definition and when compilability 
is looked for, by a semi-colon ' ;. 

Recursive definition is allowed, e.g., the reference can appears on the right hand side of the "::=". To avoid too much 
difficulties for would-be-compilers, only tail recursivity should be used, i.e., a recursive term should appear only as the 
last term of a definition. 

Examples: 





<bitpair>::=OOI01 1 10 1 11 ; 


This could have been noted as well : 




<bitpair>::= {00101 110 1 11} ; 


or 






<bitpair>::={011} {Oil}; 


Recurf 


>ive example : 




<all bit strings> ::= null 1 { {011} <all bit strings>} ; 


Anoth 


sr recursive, but not tail-recursive (and then not recommended) example : 




<all bit strings> ::= null 1 {<all bit strings> {Oil}}; 



B.1.2 Spare parts 



For the purpose of message description it is in many cases needed to specify differently the set of bit strings that are 
acceptable when received and the corresponding set of bit strings which may be sent. The second set is included in the 
first. A first example are the spare parts. 

Notations related to spare parts are different in nature from the bit string set description seen so far. They define two sets 
as the same time, the sent set and the received set. A construction rule of general application will be defined in advanced 
rules. For the moment, only two ad-hoc constructions are described. 

B. 1.2.1 Rule B7 : Spare bits 

The following construction 



<spare bit> 



describes a when emitted and a bit (0 or 1) in reception. 

B.I .2.2 Rule B8 : Padding bits 

An issue specific to the GSM radio interface protocols is that in some cases the messages cannot take arbitrary lengths. 
Padding is then necessary to fill up the message up to the desired length. Moreover, the padding uses a particular 
sequence of bits, of fixed position, i.e., the value of a padding bit depends on its position relative to the start of the 
message. The padding sequence is protocol-specific. In most cases it is constituted of all values, in which case the 
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following notation is of no use. In the case of GSM 04.08, the padding sequence is the repetition of octet 0010101 1, 
starting on an octet boundary. 

The special notations "L" and "H" are used to denote the respectively the bit value corresponding to the padding spare 
bit for that position, and the other value. 

The notations "0", "1", "null", "L" and "H" are the only terminals in CSN.l. 

Padding spare bits are bits which are set to the indicated value in emission whereas in reception any bit string is 
acceptable. The following notation 



<spare L> 



describes a bit which has a logical value L in emission, and is a bit (0 or 1) in reception 

The term <spare padding> denotes the required padding spare bits needed to fill up the message. The construction can 
be developed only partially from the rules described so far, because the length limitation does not appear in the 
following description : 



< spare padding> ::= <spare L> {null I < spare padding>} 



B.1.3 Predefined sets 

The notation allows a modular description of the messages. This means in particular the possibility to build a library of 
bit string set definitions to be used wherever needed. The following is an example of an elementary library, which could 
be specified once and can be used in other specifications without being redefined. 



<bit> ::= ( 


311 ; 




<bit(l)> 


:= <bit>; 




<bit (2)> 


:= <bit> <bit>; 




<bit (3)> 


:= <bit (2)> <bit>; 




<bit (4)> 


:= <bit (3)> <bit>; 




<bit (5)> 


:= <bit (4)> <bit>; 




<bit (6)> 


:= <bit (5)> <bit>; 




<bit (7)> 


:= <bit (6)> <bit>; 




<octet> :: 


= <bit (7)> <bit>; 




<half octet> ::= <bit (4)>; 




<spare half octet> ::= <spare bitxspare bitxspare bitxspare bit>; 


<spare padding> ::= <spare L> {null 1 <spare padding>}; 


<octet string(i)> ::= <octet>*'' ; 


— for any positive or null integer i 


<bit(i)> :: 


= <bit>(i); 


— for any positive or null integer I 


<bit string 


> ::=bit**; 




<octet string> ::= <octet>**; 





NOTE 1 : The definition of generic constructions such as <bit string(i)> is somewhat cumbersome with only the 
basic rules. More advanced rules would allow a much more compact notation. 

NOTE 2: The use of the characters "(" and ")" within a reference is done consistently with potential advanced rules. 

NOTE 3: This basic library is not exhaustive and can be extended when the needs arise. 

B.1.4 Labelling Parts 
B.1.4.1 RuleM : Labels 

Delimited names as defined by Rule B6 identify sets of sub strings. In many cases this can be used within the context of 
a message to refer to the specific part of the message. However, this is not of general application, since it may happen 
that two parts of a message follow the same structure, and economy of notation requires that the structure is described 
but once. 
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The general syntax that follows allows to refer to a part inside a description: 



<namel : string description> 



For the definition of string sets, this is equivalent to the string description being used alone. 
The name used as a label can be built according to the rules applicable to parenthesed references. 
Examples: 



<Tag : 000 > 

<Field : <Field type» 

<Field : octet> 



The third example shows the use of a non parentheses reference to obtain a more elegant expression than, for instance, 
the second example. At this stage, labels has no use for describing message syntax, but can be used to refer to the 
corresponding part of the string, e.g., in the description of the message specifying the relationship between the 
syntactical content and the semantical contents of the message, or to associate properties with effective sub-strings in 
effective messages (rather than with sets of sub strings). Syntactical use of the semantical identifier are presented in 
more advanced rules. 

The same name may appear in several places. Designers have to be careful to use non ambiguous names if non- 
ambiguous reference is desired. 

B.1.5 Goodies 

B. 1.5.1 Rule G1 : Comments 

Comments can be added, starting with the term "— " and ended by the end of line. Comments can be used in particular to 
indicate the section where a particular description can be found. 



B.2 Advanced rules 

B.2.1 Rule A2 : Exponent notation 

An arithmetic expression used as exponent after a delimited string description is used to indicate repetitions. 
A numerical expression between parentheses indicates a fixed number of repetitions. 





<octet>::= {01 1}***); 


is equi 


valent to 




<octet>::={Oll} {0 11} {0 11} {0 11} {0 11} {0 11} {0 11} {0 11} ; 


Thisc 


ould also be written : 




<octet> ::= bit(8) ; 



When the exponent is negative or equal to 0, the exponentiated construction is equivalent to the null string. 
An example of a common construction is the following : 



<name : bit(5)> 



Simple arithmetic, using numbers, terms "+" , "-", "*" and "/", and parentheses are allowed in expressions. 
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Example : 



<octet string(40)> ::= <octet> 



i*(A+i)) , 



A star used alone between parentheses, or a double star, indicates a finite, possibly null, but indeterminate, number of 
repetitions. (The star used as an exponent can be understood also as meaning the union of all the sets obtained by 
replacing the star by zero or some positive integer.) 



<all bit strings> ::= {0 II }(*) ; 
<all bit strings> ::= {0 II }** ; 



This allows a shorter notation of recursive constructions such as: 



<all bit strings> ::= {Oil } <all bit strings> I null; 



A shorter notation is allowed when the expression has a single term, consisting of a star followed by the term: 



<octet> ::= {Oil}' 


■=8; 




<octet string(40)> 


::= <octet> 


*(8*(4+l)) ; 


<allbit strings> ::= 


bit**; 





Application note : 

The indefinite exponent is usually combined with some mean to indicate to the decoder the end of the repetition. 
Different techniques exist, such as indicating in a previous field the number of repetitions. Another technique is one-bit 
tagging, an example of which follows : { 1 <item>}** 
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Annex C (informative): 
GPRS-Services sequence diagram 



Instead of providing a complete set of all scenarios, the intention of this section is to provide some typical examples. It 
shall be noted, that within the figures only those parameters of the PDUs and the service primitives are shown, which are 
needed for a general understanding of the examples. Furthermore during the examples below (except C.17) no cell re- 
selection takes place. 



SNDCP 



MS 



SM 



C.l ATTACH, GPRS only, MS unknown in the network 

GMM LLC RR RR BSSGP LLC GMM 



NET 



SM 



SNDCP 



GMMREG-ATTACl ■ 



[Attach type, 
READY-timei 
STANDBY-ti 



The oldTLLI may be a 
Local TLLI, or a 
Foreigti TLLI, or a 
Ratidom TLLI 







1 LL-UNITDATA-REQ 


GRR-DATA-REQ 


IPDLtAttachReql 


[LLC-UI, 


IMSI or TLLIpliisRAI) 


SAPI=signalling] 


oldTLLI,Cipher=off] 




LL-UNITDATA-IND 


GRR-DATA-IND 






[PDU= 


[LLC-UI] 


Identification Req] 




LL-UNITDATA-REQ 


GRR-DATA-REQ 






[PDU=Identification- 


[LLC-UI, 


Resp(IMSI), 


S API =siEnaI ling] 


oldTLLI.Ciphei^off] 




LL-UNITDATA-IND 


GRR-DATA-IND 






[PDLtAuth-Ciphcr- 


[LLC-UI] 


Req(Alji.,RAND,... 
] 




LL-UNITDATA-REQ 


GRR-DATA-REQ 






[PDU=Auth-Cipher- 


[LLC-UI, 


Resp (SRES), 


SAPI=signalling] 


oldTLLI,Cipher=off] 




LLGMM-ASSIGN-RE( 








[Kc, Algorithm] 









GRR-35ATA-IND 



[LLC=tlI, TLLI 
RALC]] 



GRR-iiATA-REQ 



[LLCfJI, 
DRX,:CLM, 

SAPIi^gnallingj 



GRR-iATA-IND 



grr-iSata-req 

-^-r 

[LLC;tJI, 

DRX^CLM, 

SAPI^gnalling] 



GRR-1)ATA-IND 



[LLC'tjI, oldTLLI] 



LL-UNITDATA-IND 



[PDU=Attach Req ( 

IMSI or TLLIplusRAI) 
oldTLLI, CI] 



LL-UNITDATA-REQ 

< 



START Tident 



[PDU= 

Identificadon Req, 
oldTLLI, Cipher=off ] 



LL-UNITDATA-IND 



[PDU=Identificatic 

Resp (IMSI), 
oldTLLI ] 



LL-UNITDATA-REQ 

< 

[ PDU=Autli-Cipher- 

Req (Alg, RAND,..). 
oldTLLI, Cipher=off ] 



LL-UNITDATA-IND 



[PDU=Auth-Cipher- 

Resp (SRES), 
oldTLLI ] 



LLGMM-ASSIGN-REQ 

■< 



IMSI fetched if 

- No GPRS MM Context exists, and 

- Attach Request without IMSI 



^1 



START Taiitli 



The network starts the 
authentication together with s( 
the ciphering mode. 
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SNDCP 



MS 
SM 



C.l (cont'd): ATTACH, GPRS only, MS unknown in the network 

GMM LLC RR RR BSSGP LLC GMM 



GMMREG-ATTACI ■ "NF 



[PLMN'sMTcap; 



STOP Tattach 



LL-UNITDATA-IND 



LLGMM-ASSIGN-RE( 



[Rx: oldTLLI or 

newTLLI 
TXinewTLLI] 



GMMRR-ASSIGN-R I ^ 



[Rx: oldTLLI or 

newTLLI 
TX:newTLU]] 



ILL-UNITDATA-REQ 
► 



[PDU= Attach cojTiplete. 
iiewTLLI,Cipher=on ] 



LLGMM-ASSIGN-RE( 



[ unassign oldTLLI ] 

GMMRR-ASSIGN- 
[ unassign oldTLLI ] 



GRR-UNITDATA-IND 

-< 



GRR-UNITDATA-REQ 



GRR-DATA-IND 



GRR-DATA-REQ 



[LLC-UI, 

S API =signal ling ] 



Implementation option; 
Unassigmnent of old TLLI e.g. 

- with receptioti of first LLC frame 
using the tiew TLLI 

- expiry of appropriate timer 



GRR-IfJ[tDATA--RE( 



[LLC;-JiID ] 



GRR-UNtTDATA-INI 



[ LLC-JitD, TLLI, CI 



GRR-lI)'ATA--REQ 



[LLCiJJI, oldTLLI, 
SAPI=^gnalling ] 



GRR-35ATA-IND 



[LLC'tjI, newTLLI 



NET 

SM 

I 



SNDCP 



Exchange of tiew INPUT 
OFSET value 



LL-UNITDATA-REQ ^j 

^ 1 

[PDU=Attacli Acc:ept( 

newTLLI), 
oIdTLLI,Ciplier=on ] 



LLGMM-ASSIGN-REQ 

-< 



|Rk: oldTLLI or 

newTLLI 
TX: new TLLI] 



LL-UNITDATA-IND 



A new TLLI 
is assigned 

START TAttach 



[PDU=Attach Completi 
newTLLI] 



LLGMM-ASSIGN-REQ 

■^ 
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MS 

SNDCP SM GMM 

GMMREG-ATTAClflEQ 



C.2 ATTACH, GPRS only, MS known in the network 



LLC 



RR 



type] 



START Tattach 



lo enable LLC lo decipher 
subsequent ciphered 
signalling messages 



. LL-UNITDATA-REQ 

I ► 

[PDU=Attach Rcq ( 

TLLlplusRAl), 
oldTLLI,Cipher=(jff ] 



LL-UNTTDATA-IND 



[PDU=Aiith-Cipher- 
Rcq (Algorithm) ] 



LL-UNITDATA-REQ 



[PDU=Auth-Cipher- 

Resp ( j, 
oldTLLl,Ciphei^off ] 

LLGMM-ASSIGN-RE( 



GRR-DATA-REQ 



[LLC-UI, 
SAPI=SLgnalliiig] 



GRR-DATA-IND 

■< 



GRR-DATA-REQ 



[LLC-UI, 
SAPI=5ignallmg] 



GRR-UNITDATA-IND 

-< 



GRR-UNTTDATA-REQ 
► 



RR BSSGP LLC 



GMM 



NET 
SM 



SNDCP 



GRR-:i;>ATA-IND 



[LLCjUL oldTLLI 



[LLC=t!I, 

DRX,-t;LM, 

SAPI^^gnalhng] 



GRR-I^ATA-IND 

— ^^^^ 



GRR-I\'ITDATA-RE( 

M^. ^ 



GRR-lffirrDATA-INI 



[ LLC-JiED, TLLL CI 



LL-UNITDATA-IND 



[PDU=Attach Rcq ( 
CKSN), 
oldTLLL CI] 

LL-UNITDATA-REQ 

< 

[ PDU=Auth-Ciphcr- 

Rcq( Algoritm), 
oldTLLI, Ciphei^off ] 



LL-UNITDATA-lND 



A new TLLl 

is assigned 



START Tauth 



^1 



[PDU= 
Auth-CiphcrRcsp, 
oldTLLI ] 



LLGMM-ASSIGN-REQ 



Exchange of new INPUT 
OFSET value 



received CKSN matches, 
start of ciphering without 
aulhcnticalion 
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MS C.2 (cont'd) ATTACH, GPRS only, MS known in the network net 

SNDCP SM GMM LLC RR RR BSSGP LLC GMM SM SNDCP 



[PLMN'sMTcap' 



STOP Tattach 



|-<- 



[ Rx: old or newTLLI 
TXinewTLLI]] 



. LL-UNITDATA-RE( I 

I ► 

[PDU= Attach complete 
newTLLI, Cipher=on ] 



LLGMM-ASSIGN-RE( 



[Kc;, Algorithm ] 
LL-UNITDATA-IND 



LLGMM-ASSIGN-RE( 



[ Rx: old or newTLLI 
TXiiiewTLLI]] 
GMMRR -ASSIGN- Rfe( I 



[ imassign oldTLLI ] 
GMMRR- ASS IGN- 



GRR-DATA-IND 



GRR-DATA-REQ 



[LLC-UI, 
SAPI=signalling ] 



;fr/iTA-REQ 



[LLCjJJI, 
SAPI^gnalling ] 



^Ul. newTLLI ] 



LL-UNITDATA-REQ _, 

-< 1 

[PDU=Attach Accept( 

newTLLI), 
oldTLLI, CLpher=on ] 

LLGMM-ASSIGN-REQ 



[Rx: oldTLLI or newTLL 
TX: new TLU , Kc, 
Algorithm ] 



LL-UNITDATA-IND 



START Tattach 



^1 



STOP Tattach 



[PDU=Attach Complete, 
newTLU] 



LLGMM-ASSIGN-REQ 

■< 

[ iinassLgn oldTLI ] 
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SNDCP 



MS 

SM 



GMM 



C.3 MS initiated DETACH, GPRS only 

LLC RR RR BSSGP LLC GMM 



NET 
SM 



SNDCP 



GMMREG-DETACF ■ 



[Detauh-ljpe, 
noma] -detach ] 



GMMREG-DETACt ■ 



GMMREG-DETACt ■ 



LL-UNITDATA-REQ 



START Tdelach 



STOP Tdelach 



[PDU=Detac:h Req, 
TLLI, Cipher^on ] 



LL-UNITDATA-IND 



[PDU=DeUn:h Accept] 



LLGMM-ASSIGN-RE{ 



GRR-DATA-REQ 



[LLC-UI, 
SAPI=signalling] 



GRR-DATA-IND 



.l;i, TLLI 



All LLC links are aborted 



LL-UNITDATA-IND 



[PDU=Delach Req, 
TLLI, CI] 



LL-LNITDATA-REQ 



[PDU=Delach Accept 
TLLI, Cipher^on ] 



LLGMM-ASSIGN-REQ 



C.4 POWER-OFF DETACH, GPRS only 



LL-UNITDATA-REQ 



I PDU=Delac:h Rei], 
TLLI, Cipher=on ] 



LLGMM-ASSIGN-RE( 



GRR-DATA-REQ 



[ LLC-UI, 
SAPI=sij;nal 



GRR-ilJ'ATA-IND 
I LLCiVl, TLLI 



LL-UNITDATA-IND 



|PDU=Dt:tach Req, 
TLLI, CI] 



LLGMM-ASSIGN-REQ 
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SNDCP 



MS 
SM 



GMM 



C.5 Network initiated DETACH, GPRS only 

LLC RR RR BSSGP LLC 



GMM 



NET 

SM 



SNDCP 



LL-UNITDATA-IND 



PDU=Del:Ldi Req] 



L-UNITDATA-REQ 



[PDU=Del:n:li Accepl, 
TLLI, Cipher=i)n ] 



LLGMM-ASS1GN-RE{ 



[ unassign TLLI] 



GRR-DATA-IND 



GRR-DATA-REQ 



[LLC-Ul, 
SAPl^signallingl 



■fcfATA-REQ 



[LLCJJl, 

SAPI^gnalling] 



[LLC' 

CI] 



All LLC links are aborted 



■i:i, TLLI 



LL-UNITDATA-REQ 



[PDU=Dt:lai:;h Req, 
TLLl,Cipht:r=on| 



LL-UNITDATA-IND 



[PDU=Dt:lach AccepI 
TLLI, CI] 



LLGMM-ASSIGN-REQ 







GMMREG-DETACH 
REQ 






1 START Tdelach 

1 STOPTdeladi 

GMMSM- 
RELEASE-IND 




[Detach-iype, 
normal-detach ] 

SNSM-DEACTIVATE 
-IND 






[TLLI 1 


[ TLLI ] 

GMMREG-DETACH 

CNF 








L Delac;h- lypej 







MS 

SM 



SMREG-PDP- 



ACKJUf- \ :k 



ACTIVATE-REQ 

► 



I START TPDP; 



C.6 PDP Context Activation, MS 

GMM LLC RR 



Initiated, MS already attaclied 

RR BSSGP LLC GMM 



NET 

SM 



l:*^ 



SNSM-ACTIVATE 



the GPRS Attach procedure shall be 
performed in case the MS is not already 
GPRS attached 



LL-UNITDATA-REQ 



LL-L'NITDATA-IND 

■< 



GRR-DATA-REQ 

► 



GRR-DATA-IND 

■< 



grr-d/Ita-ind 



[LLC;(]i, 
SAPi^ignalling] 



LL-UNlTDATA-IND 



LL-UNITDATA-REQ 



GMMSM-UNIT 



GMMSM-UNIT 
DATA-REQ 

PDU= Activate 
PDP Context 
Accept I 



START TPDPN act 
SNSM-ACTIVATE- 



TLLI. NSAPI, QoS 



ESTABLISH-REQ 



GRR-DATA-REQ 



I TLLI. SNDCP i 



LL-ESTABLISJ - 



LL- ESTABLISH- 



GRR-DATA-IND 

■< 



ESTABLISH- RSP 



I TLLI. SNDCP- :: 3 negotiated, N2(l 



I TLLI. SNC P 



exchange 
XI D 



GRR-DATA-REQ 



[ TLLI, SNDCP X r 



LL-XID-IND 



XID re-negotiates requires hnk n 



LL-XID-CNF 



I TLLI,SNDCP- :: 3 negotiated, N2(l 



I TLLI. SNCP-X [ N20' 



GRR-DATA-IND 



[LLC Xil}. priority=da 



already, 
only XID 
exchange 



LLC link exists 
already, no 
. XTD excha ng e 



SNSM-ACTIVATE- 



SMREG- 



PDP-ACTIVATE-CNF 



^TTLLI] 
STOP TPDPN act 
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SNDCP 



MS 
SM 



C.7 PDP Context Activation, Network Initiated 

GMM LLC RR RR BSSGP LLC 



GMM 



NET 
SM 



SNDCP 



[PDP- 
QoS, 



SMREG-PDP- 



P-ACTIVATE-IND 



type, PDP address, 
NSAPI, GGSN na 
ACK/UNACK ] 



ACTIVATE-REQ 



[PDU= Reqiiest- 
PDP Context- 
Acdvation] 



l-l 



PDP address, QoS, 
GGSN name, 
ACK/UNACK ] 



START TPDPact 



[PDU=Acdvate 
PDP Contest Req 



LL-UNITDATA-IND 

-< 

[SM-PDU ] 



LL-UNITDATA-REQ 



GRR-DATA-IXD 



RR-DATA-REQ 



[ LLC-UI, 
SAPI=signalling ] 



GRR-:p:ATA--REQ 



[ LLcicn, 

SAPI^gnalling ] 



GRR-;£rATA-IXD 



LL-UNITDATA-REQ 



LL-UNITDATA-IND 



GMMSM-UNIT 
DATA-REQ 



SMREG-PDP-ACnV \ 



Continued as normal MS initiated PDP context activation 



[ PDU= Rcqucst- 
PDP Context- 
Activation] 



[ PDP-type, PDP-add]. 
QoS, NSAPL 
GGSN name, 
ACK/NACK ] 

START TPDPN act 




STOPTPDPNa. 
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C.8 Anonymous PDP Context Activation 

LLC RR RR BSSGP LLC 



GMM 



NET 

SM 



SNDCP 



ACK/l ^ \CK 



P-ACTIVATE-R TO j START TPDP.a 



STOPTPDPA 



SNSM-ACTIVATE 



LL-UNITDATA-REQ 



LL-UMTDATA-IND 
M 



GRR-DATA-REQ 

>- 



GRR-DATA-IND 

-< 



GRR-DATA-IND 



[LLC;l:i, 
SAPJ^ignalling] 



LL-UNITDATA-IND 



LL-UNITDATA-REQ 



SNSM-ACTIVATE- 



I TLLL NSAPL QoS 



ESTABLISH-REQ 



GRR-DATA-REQ 

>■ 



LL-ESTABLISI - 



J. SNT)CP-XID II 



[ TLLL SNDCP X I 



XID re- negotiates requires link n 



LL-XID-CNF 



I TLLI, SNDCP. K E 



GRR-DATA-IND 



GRR-DATA-REQ 



GRR-DATA-IND 



SNSM-ACTIVATE- 



SMREG-AA-I [ '-ACTIVATE-CNT 



LL- ESTABLISH- 



TLLL SNCP-XID 



quested, N2II1 ] 
ESTABLISH-RSP 



grr:-data-ind 

|LLCXID^.| 



|LLC XitJ, prionty=i 



I TLLLSNCP-X [ N20' 



LL-XID-RSP 



I ACTIVE 



STOP TPDPN iU 



exchange 
XID 



already, 
only XID 
exchange 



LLC link exists 
already, no 
.Xllie\cl]an££ 
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SNDCP 



MS 

SM 



C.9 PDF Context Deactivation, MS initiated 

GMM LLC RR RR BSSGP LLC 



GMM 



NET 

SM 



SNDCP 



)EACTIVATE-REQ 



SNSM-DEACTIVATE 



-^ 



START TPDP deacl 



GMMSM-UNIT 
DATA-REQ 



[ PDU=Deaetivate 
PDF Contest Req 



■ rpnii^n 



^-RELEASE-CFN 



SNSM-DEACTIVATE 



'DP-DEACTIVATE-CNI 



LL-UNITDATA-REQ 



LL-UNITDATA-IND 



GRR-DATA-REQ 



ILLC-UI, 
SAPi^signallingl 



GRR-DATA-IND 



iiATA-REQ 



The release is only requested, if the LLC link Is not used 
by any other PDP contest using aek mode 



LL-UNITDATA-IND 




GMMSM-UNIT 
DATA-IND 




SNSM-DEACTIVATE 
-IND 




ISM-PDL 1 

LL-UNITDATA-REQ 


|PDU= 

Deactivate PDP 
Contest Req ] 

GMMSM-UNIT 
DATA-REQ 


[SM-PDU ] 


1 PDU=Deactivate 
PDP Contest 
Ateept ] 


LL-RELEASE-REQ 


[ NSAPI(s) ] 


[ local TLLI ] 








LL-RELEASE-CNF 












1 TLLI 1 

SNSM-DEACTIVATE 
-RES 




[ TLLI 1 
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MS c.lO PDP Context Deactivation, network initiated NET 

SNDCP SM GMM LLC RR RR BSSGP LLC GMM SM SNDCP 



SNSM-DEACTIVATE 
-IND 

< 



LL-RELEASE-CFN 

< 



SNSM-DEACTIVATE 



SMREC -1 DP-DEACTIVATE-INI 



[ PDU=Deaetiva!e 
PDP Contesl 
Re que SI] 



PDL=Deacti 
PDP Cdiitex 
ACCEPT I 



LL-UNITDATA-IND 

-< 



LL-LNITDATA-REQ 



GRR-DATA-IND 

■< 



GRR-DATA-REQ 



[ LLC-UA, 
SAPI^signalling | 



GRR-lViTA -REQ 

■<r^. 

|LLC^l;i, 
SAPI«;^gnalling| 



GRR-lViTA-IND 







GMMSM-UNIT 
DATA-REQ 


1 
1 


SMREG-PDP-DI 




ACTIVATE-RE 


LL-UMTDATA-REQ 


[NSAPII 
START TPDPNdeact 

STOPTPDPNdesel 

SNSM-DEACTIVATI 
-IND 






ISM-PDU 1 

LL-UNITDATA-IND 


1 PDU^Destlival. 
PDP Comesl 
REQUEST 1 

GMMSM-UNIT 
DATA-IND 




[SM-PDU 1 


1 PDU= 

DsiiclivalePDP 
Comexi Accept 




LL-RELEASE-REQ 


INSAPIMI 




1 liical TLLI 1 








LL-RELEASE-CNF 


i 












1 TLLI ] 

SNSM-DEACTIVATE 
-RSP 






1 TLLI, 1 
SMREG-PDP-DE 


TIVATE-CNF 






INSAPI] 
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MS 

SNDCP SM 



GMM 



C.ll PDF Context Modification 

LLC RR RR BSSGP LLC 



NET 

GMM SM 



SNDCP 



SNm- 



■MODIFY-IND 



LL-RELEASE I ID 



SNSM-MODIFY-RSP 



SMREC - DP-MODIFY -IND 



[ PDU^Modily 
PDF Comext 
Request) 



I PDU=Modily 
PDP Conlesl 
Aeeept] 



;STABLISH-IND 



[ TLLI, SNDCP XI ) eque^ted. N201 | 
.-ESTABLISH-RSP 



[ TLLO. SNDCP-X C iiegoliated 



LL-UNITDATA-IND 

■< 



LL-UNITDATA-REQ 



GRR-DATA-IND 



GRR-DATA-REQ 



I LLC-UI. 
SAPI=signalling | 



GRR-DATA-IND 

< 



GRR-DATA-REQ 



GRR-DATA-IND 



GRR-DATA-REQ 



ILLC-'UI, 
SAPIsi^gnallingl 



[LLC-Ut-TLLI,CI] 



[LLC^qiSC, 
SAPI^la] 



I LLC-Uft. TLLI, CI I 



GRR-Qi\TA-REQ 



I LLC-CH: TLLI, CI | 



LL-UNITDATA-REQ 



LL-CNITDATA-IND 



LL-RELEASE- 



DATA-R 



I START TPDPN mod 



[ PDU^Modity 
PDP Conlext 
REQUEST ] 



^1 



|PDU= 
Modify PDP 
Contesl Accepl | 



STOP TPDPN mod 
SNSM-MODIFY-IND 



[TLLI, NSAPI(s) + 
new QoS(s) ] 



17 



NoleiThe release is only requested, if the link is not 
used by any other PDP context using ack'ed mode 



LL-ESTABLISE I EQ 



TLLI, SND( I XID requested | 



(ELEASE-CNF 



^STABLISH-CNF 



I lnegotiated.N201| 



SNSM-MODIFY-RES 



i TLLI I 

SMREG-PDP- 



! lODIFY-CNF 



NOTE: The standalone PDP context modification procedure should use graceful disconnection of the LLC link 
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SNDCP 



MS 

SM 



GMM 



C.12 MO Data and MO-SMS transfer 

LLC RR RR BSSGP LLC 



NET 

GMM SM SNDCP 



LL-DATA-REQ 



[TLLl, N-PDU, loca 



1-^ 



LL-DATA-CNF 



[TLLI, local rt '. 



GRR-DATA-REQ 



[ LLC-1, 
SAPI=d:[ia 1 



GRR-DATA-IND 



grK-;e 

I LLC-I 



LLGMM-TRIGGER-IND . 



^■tlATA--REQ 



[LLC-JtR, 
prioifljt^aia] 



-^1 



LL-DATA-IND 



[N-PDU, TLLl, 
local ref. J 



SMS 



UNITDATA-REQ 



ITLLl, SMS-CP-P 5 J I 



GRR-DATA-REQ 



I LLC-Ut,-1 



LLGMM-TRIGGER-INE 



^11 



SMS 



LL-UNITDATA-IND 



[ SMS-CP-PDU, TLLI 
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SNDCP 



MS 

SM 



GMM 



C.13 Paging and MT Data transfer 

LLC RR RR BSSGP LLC 



GMM 



NET 

SM 



SNDCP 



LL-DATA-IND 



TLLI, N-PDU, lota 



LLGMM-TRIGGER 
RESTART J '^^Q 
READY-timer 



A LLC frame is 
sent, see 'CeU 
update', CI7 



LLGMM-TRIGGEi . 
RESTART I ^ -^ND 
READY -time 



GRR-DATA-REQ 



I LLC-PDU, 

SAPI^data | 



GRR-DATA-IND 



I LLC -I I 
GRR-DATA-REQ 



I LLC-RR, 
SAPI^^data | 



Normal LLC traffic continues 



LLGMM-SUSPEND- I i( 




READY-timer 
expires 



LLC Ls suspended, 
MM in STANDBY, 
cause indicates that paging 1 
required if data has to be se 



GIviMRR-PAG ;- iEQ I 



|TLLi;iMSI,CI 
or CC-;kt or RAL 
SAPJtsignalling | 

GRRl-^DATA-INE 



|LLC^PDU,TLLI 



GRR*DATA-RE j 



ILLC^t; 

SAPI^atal 



grSidata-ine 



[LLC-:kR,TLLLC 



LL-DATASEN' 
-IND 



I ITLLI, local ref., 
V(S)| 



LLGMM-P AGE-IN > 



LLGMM-TRIGGEI 
RESP-IND 



LLGMM-RESUME-f I 



^T?ni7^ 



LLC is resumed, 
MM in READY 



LLGMM-TRIGGER-I 



START 1 
timer 



RESTART 
READY-timer 

STOP PAGIN( i 
timer 



[GGER-WD 

'Tl ' 



RESTART 
READY-timer 



I N-PDU, TLLI, 
local ref. | 



LL-DATA-CNF 



TLLI, local ref. | 
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SMS 



MS 
SM 



C.14 Paging for SMS and SMS-MT transfer 



GMM 



LLC 



RR 



LL-DATA-IND 



L TLU, SMS-CP--PDU 



LLGMM-TRIGGER-RI C 



GRR-DATA-REQ 



GRR-DATA-IND 



RR BSSGP LLC GMM 

LLGMM-SUSPEND-RECT 



NET 



SM 



SMS 



?[TLLI. 







LLC is suspended, 
MM in STANDBY, 
cause indicates that paging is 
required if data has to be sent 



[TLLI;4MS1, CI 
or Cl-ilSl or RAl, 
SAPli>iignalUng 1 



GRR-EtATA-IND 



[LLC-PpU, ™ 

cu :;: 



GRR^pATA-REQ 



[LLC-bt 
SAPI=JiJUS] 



Normal LLC traffic continues 



LLGMM-PAGE-IND 

> 



START PAGING 



LLGMM-TRIGGER-IND 



-^|< 



LLGMM-RESUME-REQ 




STOP PAGING 



[SMS-CP-PDU, TLLI 



£75/ 



(GSM 04.07 version 6.5.1 Release 1997) 



115 



ETSI TS 100 939 V6.5.1 (1999-11) 



SNDCP 



MS CIS Generic Routing Area Update, Intra SGSN net 

SM GMM LLC RR RR BSSGP LLC GMM SM 



SNDCP 



LLGMM-SUSPEND 
-REQ 



LL-UNITDATA- 
REQ 



LPDU^ 

RA Update Req ( 

TLLI plus old RAl), 
Cipher-off ] 



LL-UNITDATA-INE 



LPDU=RA Updaie- 
Aceepi (new TLLI) | 



LLGMM -ASSIGN -RE( 



GMMRR-ASSIGN-RB ) 



LL-UNITDATA- 
REQ 



[ PDU=RA Update 



SMM-RESUME- 
REQ 



LLGMM-ASS1GN-RE( 

> 

[ unassign oldTLLI 

GMMRR-ASSlGN-REt I 
[ unassign oldTLLI | 



GRR-DATA-REQ 



GRR-DATA-IND 



GRR-DATA-REQ 



[ LLC-PDU, 
SAPl-signalling 1 



GRR--BATA-IND 



[LLE? Ul, 
oldyUA, CI] 



[LLC-tu: 
SAPI-sJgnalling \ 



[LLC PDU 
new^TLLI, CI] 



The oldTLLI may be a Local 
TLLI, or a Foreign TLLI, or a 
Random TLLI 



[PDU- RA Update Req ( 

TLLI plus RAI), 
oldTLLI, CI ] 



Security lunclion may be invoked 



LL-UNITDATA-REQ 

■< 

[PDU -RA Update- 
Accept (newTLLl) ] 



LLGMM-ASSIGN-REQ 



[ Rx: newTLLI or 

t)ldTLLl 

Ts: new TLLI ] 



LL_UNITDATA_1ND m 

>►! 

[PDU-RA Update Compl 
newTLLI,CI ] 



LLGMM-ASSIGN 



-RH^ 
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SNDCP 



MS 

SM 



C.16 Routing Area Update, Inter SGSN 



GMM 



LLC 



RR BSSGP LLC 



GMM 



NET 

SM 



SNDCP 



LLGMM-SUSPENI 
-REQ w 



START 

Trams 



LL-UNITDATA- 
REQ w^ 



X-RESET-IND 



SNDCP suspends transmission 
for NSAPIs using ack mode 



;STABLISH-INE 



[S|S1 3CP XID requesi :<|l 
■STABLISH-RSI 



[SsJ^CPXIDnegoli; a i] 



{ PDU-Routing 
Area Update Reques 
Cipher^off ] 



GRR-DATA-REQ 



[ LLC-UI, 
SAPI^signalling ] 



GRR-CtfiTA-IND 



[LLC-PpU, 
oldTLlij, CI 



Security function may be invoked 



RESET and lOV-UI sent, possibly together 
with SNDCP/LLC XID exchange 



GRR-UNITDATA-IN 3 



[ Reset, lOV-UI, LLC 
GRR-UNTTOATA-RI C. 



GRR,-UNITDATA-nSl 3 



[ LLC-SABM 1 

grr-unitdat; 



LLC-UA, SAPI^dat l 




-T|jN m)ATA-REO 
, lOV-UJ- LLC-XIDl 



^fiR-UP-alrDATA-INI ' 



LLC-:;^, TLLI 



-UNnxjAi 



I LC-SaSm. SAPI^d 

■UNnxJATA-IND 
LLC-UA^nXLLCn 



LL< 



LL-UNITDATA-IND 



[PDU-Routing Area 
UpdateRequest, 
oldTLLI, CI]] 



.GMM-ASSIGN- 



[Kc, Algorithm] 



LLGMM-RESET-RE 



LLGMM-RESET-C^ F 



LL-ESTABI I ;H-REQ 



:r 



[SNDCP XI i requeseted] 
LL-ESTABI .1 ;H-CNF 



[SNDCP XI i negotiated] 



See 'Routing area update, inter SGSN, old 
SGSN' in the GTP protocol. The new SGSN 
receives : 
- MM and PDP contexts, with Send and 

Receive N-PDU number if ack'ed mode 

is used 



LL-RESET-ff r 



SNDCP suspends transmission 
for NSAPIs using ack mode 



Sent for every PDP context to be 
created in the new SGSN 



SNSM-MODIFJ-D^ D 



[TLLI, NSAPI, QoS 



Establishment and/or XID 
Negotiation, as required 



SNSM-> 



Receive N-PDUs tunnelled from the old 
SGSN. For ack'ed mode N-PDUs, N-PDU 

number is also received if assigned. 
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SNDCP 



MS C.16(cont'd) Routing Area Update, Inter SGSN net 

SM GMM LLC RR RR BSSGP LLC GMM SM 



SNDCP 



Vl-SEQUENCE-INI > 

< 

ILLI, NSAPI, 

Rx N-PDU number 



STOP 

Trams 



LL-UNITDATA-IN Z 



[PDU^RAUpdaie 
Rx N-PDU numbefe 



4.i|ccpt[ [LLC-PDUl 
Cipher! 



Sent for each NSAPI using ack mode. 
SNDCP deletes buffered N-PDUs 
received by SGSN, and begin re- 
transmitting all buffered N-PDUs. 



Sr J M-SEQUENCE-RE 



I FLLI. NSAPI. 
Rx N-PDU niimber 



Unassignment of old TLLI may be 
delayed so that SABM/XE) sent on 
the old TLLI may be received 



:,LGMM-ASSICN-RE3 



cw TLLI. KcT- 

gmmrr-a: 



LL-UNITDATA 
-REQ 



RA Updalt: Cuiiipl 
RxN-PDUiiui.±icr,CiphJi 



LLGMM-RESUME- 



iCMM-ASSIGN-REQ 



I luiiissii;.! uldTLB 
GMMRR- ASS IGN- REQ 



GRR-DATA-INE 



GRR-H? 



HATA-REQ 



f LLC-it'XJU, 
SAPEikignalling 



Establishment and/or XID 
negotiation on non-signalling SAPIs 
may still be outstanding when RA 
update accept is sent 



GRR-DATA-REQ 



:.L-UNITDATA-REQ 



:'DU^ RA Updaie -Ai " pi [ 
Rx N-PDU numbers, C ipher 



LLGMM-ASSIGN-I 



"Rx: new TLLI or 

oldTLLI 
Tx: newTLLI ] 



LLUNFTDATA 



^1 



LLGMM-ASSIGN-REQ 



STAR" ' 

Trail 



Sent for each NSAPI using ack mode. 
SNDCP deletes buffered N-PDUs 
received by MS, and begin re- 
transmitting all buffered N-PDUs. 



PDP CONTEXT Modification may be requested (optional) - see figure C. 1 1 



SNSM-SEQLENCE-INE 
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MS 

SNDCP SM 



GMM 



LLC 



C.17 CELL UPDATE 

RR RR BSSGP LLC 



NET 
GMM SM SNDCP 



RESTART 
READY 

-timer 



LLGMM-TRIGGER 
-REQ ^ 



If no LLC frames 
pending and LLC in 
ABM, send a 
supervisory frame, 
e.g. RR 



If LLC frames 
pending and LLC 
in ABM send e.g. an 
IPDU 



If LLC in ADM, 
then a Ui Ls sent. 



GRR_DATA_REQ 



I LLC-RR, 
SAPI=data | 



GRR_DATA_REQ 



LLC-I, 
priority=utiitdata | 



GRR_DATA_REQ 



LLC-UL 
priority=u nit data | 



GRR_pATA IND 



[LLC 
CI] 



El ATA IND 
TLLI, 



[LLC 
CI] 



C)ATA IND 
-tJM, TLLI, 



LLGMM-TRIGGER 

TND ^^y RESTART 

r"! READY 

-timer 



I TLLI, CI I 



LLGMM-TRIGGER 
IND ^_ U RESTART 

READY 

-timer 



I TLLI, CI ] 



:*-! 



LLGMM-TRIGGER 
-IND ^ g 

^^1 READY 
I TLLI, CI 1 n -timer 



LL_DATA_IND 



I N-PDU,TLLI, 
local re f.] 
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Annex D (informative): 
Change Request History 



SMG# 


CR 


rev 


phase 


VERS 


new_vers 


SUBJECT 


25 A015 1 R97 5.3.0 6.0.0 Page response parameter introduction between GMM-LLC-GRR 


26 


A014 


1 


R97 6.0.0 


6.1.0 


Primitives MMXX_PROMPT_IND, MMXX_PROMPT_REJ added 


27 


A019 




R97 


6.1.0 


6.2.0 


SNSM Primitives 


27 






R97 


6.2.0 


6.2.1 


Correction of CR implementation 


28 


A017 




R97 


6.2.1 


6.3.0 


Introduction of Service primitives for the GMMSMS-SAP 


28 


A020 




R97 


6.2.1 


6.3.0 


Enhancement to CSN.l Definition in 04.07 Annex B 


28 


A021 


1 


R97 


6.2.1 


6.3.0 


Inter-SGSN RA update 


29 


A023 


1 


R97 


6.3.0 


6.4.0 


Inconsistency in definition of comprehension required lEs 


29 


A024 




R97 


6.3.0 


6.4.0 


Inter-SGSN RA update 


30 


A031 




R97 


6.4.0 


6.5.0 


Addition of LL-STATUS-IND 
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History 



Document history 


V6.1.0 


July 1998 


Publication 


V6.2.1 


November 1998 


Publication 


V6.3.0 


April 1999 


Publication 


V6.4.0 


August 1999 


Publication 


V6.5.1 


November 1999 


Publication 
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